NCD PR33-17 Bus Scan causes unrecoverable state

I am interfacing with a RHT sensor through the PR33-17, but having difficulty getting the port scan to work.

When I try to read from the device, I get a 0x5e acknowledgement error, the same as if I use a nonsense address. That leads me to suspect that my sensor may not be detected, or may have a different address. I’m trying to do a bus scan to confirm.

Send: aa 02 c1 00 6d
Recieve: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 (109 null bytes)

After this, the PR33-17 does not communicate over serial, and seems unrecoverable with anything short of unplugging and re-plugging the device. (For instance, hard resetting does nothing).

I believe I am using the firmware version 6 because when I send the soft reboot command I get a confirm reply.

Send: aa 03 fe 21 bc 88
Recieve: aa 01 55 00

And when I send a hard reboot I do not get a reply for several seconds, and then the device returns to functioning normally. As both of those are firmware version 6 features, it seems like I should have support for the bus scan as well.

Please use Alpha Station to scan the bus and check the firmware version. https://ncd.io/alpha


Alpha Station connected to COM-5


I2C Quick Scanner after pressing the “Scan all I2C ports” button doesn’t seem to discover anything. After pressing that button, closing Alpha Station and reopening fails to bring up the firmware label:

Additionally, connecting directly to the serial, the PR33-17 does not respond to any communications, suggesting it is in the same unrecoverable state. My suspicion is that the “Scan All I2C Ports” button sends the same API command as I am sending to the PR33-17 directly?

Thank you for the advice, let me know if this suggests additional avenues.

Click on I2C Converter Configuration, at the bottom right corner of the window you should see firmware version 6, if not, you have a older converter that does not support the scan feature. We can update firmware for you, but it requires a return. If you do see firmware version 6, there is a hardware error. The CPU Does use a hardware watchdog, if it locks up, it should automatically recover in about 20 seconds or so.

The watchdog doesn’t seem to work, because it stays locked for as long as I wait.

What type of device do you have connected to the I2C port?
Please remove all devices and re-scan just to verify the scan is completing without problems.
Thanks,
Ryan


Removing all devices, I get this, and the problems do not occur (in terms of locking up after querying serial)

The raw serial is

aa 01 ff aa

Is that an expected result?

The sensor is a SHT3x RH/T sensor (non-NCD) on, supposedly, port 0x44. (https://www.sensirion.com/en/environmental-sensors/humidity-sensors/digital-humidity-sensors-for-various-applications/) It looks like the issue might be on that side, then?

When you send a scan command, the controller scans through every start address waiting for a response. If the device locks up, it’s because the I2C data line is held in a low state when the controller is expecting it to be released. The controller cannot scan to the next device if this occurs. Check your wiring carefully, and remember, our I2C adapter is a 5V adapter, this includes both power and data lines. Make SURE you are able to power your SHT3x at 5V and that it is safe to use 5V logic. When buying sensors from us, we include level shifters for 3.3V devices. Check your wiring and particularly your power to the chip. Also, remove the pull-ups that you may have connected to your chip on the I2C lines, our converter does this for you (it is the responsibility of the master I2C device controller to handle this for all attached nodes). Hope this helps.
Ryan