Hi. I’m currently trying to control the A2D ADS7828 on the PR2-7 board using the PR33-17. I’m sporadically getting the 0x5e timeout/chip did not acknowledge error code as defined here: Serial to I2C Conversion - NCD USART to I2C Converter Protocol. This seems to only occur during the reading of the sampled value back from the chip. I never run into it when setting the command byte. Based on the documentation
A fixed timeout is hard-coded into the firmware. Should a chip exceed this preset timeout, you will receive an Acknowledgement error.
May I ask what is that timeout? I’ve been unable to capture a trace of the failure since I can’t consistently reproduce it. However, I did notice that there is a delay (what appears to be clock stretching?) by the master sending an ACK or NACK back to the chip after the read. See attached scope capture. I assume this is normal behavior? I’m also confused why I’m getting the error during reads of the A2D, when the master should be the one sending the ACK of the data read back.
I was also trying to see if I can exacerbate the issue by increasing the I2C bus frequency. Using Alpha station to configure the I2C port speed to 400kHz, it appears to write successfully to the EEPROM and I can load it back even after loss of power. However, when I send anything over the bus, it continues to send at 100kHz. I’ve tried other frequencies and none of them seem to affect the actual speed.
Any help with why I might be getting the 0x5e timeout and why configuration isn’t working would be greatly appreciated. Thanks!
Bump. Any insight at all from the NCD team? If someone could just help with how to configure the PR33-17 to run at 400kHz, that would be a start. Thanks.
I am working remotely and I do not have this setup in front of me to help with troubleshooting or to duplicate your results. Last known testing was operational at 400KHz, but given the bottleneck in communications is serial based, I would not hesitate to run at 100KHz as there is very little difference in real-world speed. The I2C clock stretching timeout is pretty close 1 second if I recall correctly, which is plenty of time for this ADC. Also, Alpha Station software has a demo for this chip that is operational, you might give it a try and let me know if this helps: https://ncd.io/alpha
Thanks for the reply @ryan1. I’m trying to operate at the 400kHz bus speed to see if I can more easily reproduce the issue I’m facing rather than improve on overall speed. I’m mainly after what could cause a 0x5e error to see if I’m doing anything wrong in my code which is using the NCD serial API protocol.
Hi Alex, I just checked the firmware for PR33-17 and as you pointed out, this is an ACK error, which means the device did not acknowledge. I can only suggest a short delay between commands to see if this resolves the problem and to test with our Alpha Station sample to see if you receive the error using our reference code for this chip. Beyond this, I do not have a recommended suggestion at this time, but I will think about this further to see if I can come up with any ideas.
I would like clarification on one last thing in my efforts to understand the problem. To get a reading off the ADS7828, a command byte is first sent which specifies which channel to sample. Afterwards, an I2C read of 2 bytes is sent to get the sampled value. The sending of the command byte is always succeeding for me, but the subsequent read is when i’m getting the 0x5e no ack error.
The NCD API indicates that 0x5E error is the chip did not acknowledge. However, in a read scenario, shouldn’t the master be the one sending the acknowledge that it received the byte read from the chip? Why would I get a chip did not acknowledge error. The only ACK from the A2D chip during a read should be for the address byte, but I would think if it didn’t acknowledge the address, I would be getting a 0x5B (chip did not respond) error instead. Can you clarify from the firmware exactly what would cause the 0x5E error if my assumptions are correct here.
The master sends the clock and data, it is the responsibility of the slave to acknowledge bytes as they are transferred from the Master to the Slave:
As for protocol, Alpha Station has an example that shows proper implementation for this specific chip, this chip has a few options which are covered in the UI example. I strongly advise seeing if the problem appears in Alpha Station and reviewing the source code as protocol is demonstrated in the source along with option settings.
In my scenario, it is the slave ending data back to the master though so the master should be the one acknowledging. The following is from the ADS7828 data sheet where the gray A indicates the ack is coming from master to slave:
The only ack from slave to master should be of the addressing, which is where I expect a 0x5B error if that was the case, and not 0x5E.
I have the latest version of Alpha station downloaded and did not see support for the ADS7828 chip.
I do not have these items in front of me, so I cannot replicate your results. The source code is showing support for the ADS7828, were you able to run the software on your computer?
