I am using the ‘USB to I2C Converter with Virtual COM Port FT230XS’ by talking directly through serial (not AnyI2C) and it is generally working very well, thank you! However, I have a couple questions.
Firstly, are the commands discussed in this thread from 2018 still supported?
Second, I came across an interesting phenomenon with my setup and I’m hoping you might have some insight into whether it’s preventable/recoverable.
In my setup, the NCD converter is used to connect a computer to external I2C devices which have their own power supplies. The grounds are shared so I2C communication is possible.
The computer program sends messages packed using the NCD API to the converter and the messages are distributed onto the bus
When the external devices (arduino I2C slaves) are powered, everything works well, communication is great
If the external devices are completely disconnected, I can still send the serial bus scan command and get a response from the converter
However, if the external devices are connected to I2C but disconnected from power, the NCD converter stops responding to the computer. I presume this is because the external devices are pulling down the converter’s SDA/SCL power and stopping it in some way. This is somewhat understandable
My main question is whether there is a way to recover the converter’s state after this scenario occurs. Currently after hitting this state the converter stops and will not respond even once normal power is restored
I tried sending both the hard and soft reboot commands to no avail
It appears that the employees here are great at responding to all/most posts, but maybe this got lost as the last post on a Friday. Any thoughts? If there’s no ‘fix’, this is behavior I can live with but I would like to explore my options before treating it as a fact of life.
Hi Ethan,
I am very sorry for the delay, I did spend some time reviewing the firmware. One thing we always do is make sure there are no loops the device can get stuck in. Internally, we use a I2C Timeout to prevent the condition you describe. We also employ a watchdog timer, which should reset the device after several seconds should it get stuck somewhere else in firmware. I believe I bench tested the scenario you describe to prevent the device from getting “stuck”. After a firmware review, I was not able to find any loops that can cause a lockup. One thing I would look into though, this may not actually be a I2C bus problem at all. You might close the virtual COM port and reopen the port, I am wondering if the electrical changes such as ground connections between devices are causing the USB to serial port converter to close the port as USB is very sensitive to these kinds of changes. I am starting to think the problem is with actual USB virtual com communications. You might make sure the device still shows in your device manager. Usually, you can recover by closing and re-opening this virtual port. Please give this a try before we move any further on this issue.
Thanks,
Ryan
Hi Ryan, thanks for the response. The I2C converter device is still present in device manager as “COM9”. Is there a way to further reset it through software?
And on the PC side, I’m using the npm Serialport library. I doubt it makes much difference, but I also tried to close/reopen the Serialport connection. Once the bus loses power, I can’t get the commport to reply to any massages including a standard busScan, even once power is restored.
I just encountered something I hadn’t noticed before while looking more closely into exactly what’s returning from the serialport.
I found that removing the bus power for a short time did cause the NCD converter to stop responding while bus power was disconnected, but once power was restored, the NCD started talking again like nothing had happened.
I tried to probe what the time limit was, but instead I now believe that time isn’t the issue, it may be some sort of input buffer inside the converter. I am seeing that I can reliably and consistently follow these steps:
Recovers:
Connect to NCD Converter with powered bus
Send a Bus Scan command - works
Disconnect bus power
Send 9 Bus Scan commands (5 bytes each, 45 total) - no response returns through the serialport
Reconnect the bus power
Send another Bus Scan command - works
Does not recover:
Connect to NCD Converter with powered bus
Send a Bus Scan command - works
Disconnect bus power
Send 10 Bus Scan commands (5 bytes each, 50 total)
*** No response returns through the serialport to the first 9 commands
*** The final command returned 109 zeroes through the serialport (though the two appear to be split in time to the first 15 zeroes and the following 94 zeroes)
Reconnect the bus power
Send another Bus Scan command - still does not respond
If this is a more accurate representation of the problem, it’s possible that the confounding factor for me is that previously I had set up processes to be constantly checking in with devices over the bus so the buffer limit was reached extremely quickly.
I will check this when I get a moment to see if I can replicate the results.
While the I2C converter does have a buffer, it will reject and reset about anything that it finds invalid.
Thanks,
Ryan
Hi Ethan,
I was not able to recreate your test using the PR33-17 and a stock NCD I2C 1-Channel Relay Controller.
I used Alpha Station for a user interface and I confirmed the device never failed to respond regardless of conditions. The converter will report a FF during device scan if a remote device is unreachable, otherwise, it will report the address of the device, a locking condition never occurred regardless of scan frequency or power cycling the remote I2C node. It might be helpful to know what device you are connecting to the PR33-17. Also, I did notice that once power was disconnected from the remote relay board, it lost it’s I2C device configuration. The remote I2C node needed to be re-initialized to continue proper operation (this is to be expected).
Thanks,
Ryan
(I’m using an arduino nano set up as an I2C slave as my I2C device. Instead of the Wire library I use SBWire to allow I2C communications to time out rather than hang. However, given that I can make the PR33-17 not respond even with the arduino disconnected, I struggle to see how that could be to blame.)
In that case I’m most likely doing something wrong, but just to confirm, would you mind following this simple procedure I tried on my Alpha Station? (I also attached some images at the end so you can see whether we’re on the same page)
Connect the remote power to the external I2C device.
Connect the PR33-17 to the computer via usb (PR33-17 powered from computer)
Connect the PR33-17’s SDA, SCL, Gnd (NOT 5V) to the external I2C device
Launch Alpha Station, and choose the correct Comm port and baud rate (COM9 and 115200 in my case)
Alpha station opens and has detected the PR33-17. Choose “I2C Quick Scanner” to allow bus scans to be run.
Run a bus scan on Port 1, the input field populates with the address of the connected device (&H23 in my case)
Disconnect the SDA, SCL, Gnd wires between the PR33-17 and I2C device. Rerun the bus scan and now the field reports &HFF. Great.
Reconnect SDA, SCL, Gnd. Rerun the bus scan and the I2C device is back (&H23 reappears)
Now the real test, disconnect the remote power from the I2C device, and try to run the bus scan. This time the button grays out for a moment, while it attempts.
Rerun the bus scan ~20 times (overkill to be certain fully tested on your end). The input field will remain unchanged with the device’s address (&H23 in my case), though I fully believe this to be a leftover value in the box that wasn’t updated due to the failed scan
Reconnect the remote power to the I2C device, and try using a bus scan to detect it’s presence. The device address is there, unchanged from before, though as mentioned, I believe this is a leftover value
To test this, again disconnect the SDA, SCL, Gnd wires between the PR33-17 and I2C device. Run the bus scan and we would expect &HFF, however, the value still remains unchanged for me at &H23. If this works for you than the problem is strictly on my end and it will probably go unsolved.
I can no longer get accurate bus scans from the device at this point, so my last attempt is to restart Alpha Station.
Close and restart Alpha Station → Select the same Comm Port/Baud Rate
When Alpha Station connects there’s only a couple options, unlike before. So I this the PR33-17 is no longer responding as expected
If you don’t encounter the issue than I’ll probably let the matter drop, but I figure this is worth one final test using the same platform.
It might be helpful to look at Device Manager while following these steps to see if the device drops off the USB bus, I suspect the device may disappear from device manager, then re-appear, which will cause all kinds of software issues that would require a re-launch of the software. Just a thought, please let me know what you find. -ryan
Same guy here from the other post regarding the PR33-17 clock line hanging low. Given that you mentioned the project is closed in the other post and that the part works mostly fine for me anyway, I’m going to close this thread as unresolved. Thanks for your help.
