I require your help regarding a problem I’m encountering.
Description:
When i tried to use a board development (mimxrt1010-evk) to communicate with board SCC-32U via USB, the rx led turn on to indicate that chip ftdi received data. But the led A/B didn’t work to signal whether the byte received is valid ot not. On my board development, i don’t have driver usb ftdi, i customized the API CDC ACM from NXP. So, i don’t know which is the problem in my case? if RX leds turn on, can i make sure that the data is received correctly with ftdi chip, it means the fldi chip is not the problem here ?
It sounds like you do no have power properly provided to the SSC-32U. Typically, you’ll need 6 V DC on the VS1 screw terminal for the board to be powered. Is your blue PWR LED turned on? If not, then you have not powered the SSC-32U properly.
Please note that the USB interface (by design / for safety reasons) does not power the SSC-32U, only the FTDI interface.
To power the board, the RC servomotors and its microcontroller (and A/B LED), you’ll need to provide a 6 V DC power source of sufficient current to the VS1 input / screw terminals. Make sure to respect the polarity (written on the silk screen of the board) and ensure that no loose strands touch across the terminals if using wires made of multiple strands (vs solid core). If so, it can help to “tin the tip” of the wires before inserting them into the screw terminal.
In fact, i have powered correctly for the SSC-32U with 6V DC on the VS1. The led Blue turned on also. So i don’t think that the problem is the lack of voltage on board SSC-32U. I control successfully the arm AL5D via the PC, but when i tried to use board imxrt1010-evk, it didn’t work, it seems that when chip ftdi receive data from my board (the led RX turned on) but the driver on board imxrt1010 is not good, so the ftdi can’t interpret the set of data and transfer forward to the SCC-32U. I don’t know whether the led RX turned on means ftdi chip received correctly data or not? i’m a newbie on this chip, how it operates.
Good to know. You’d be surprised how many times this happens…
Also good to know. We can at least rule out a defective SSC-32U, power source or FTDI/USB connection (from the SSC-32U’s side, at least).
It definitely seems like you have a driver issue on your development board.
If you are using a specific OS, the best would be to go to contact either a support forum/repository issue system/maintainers for said OS and ask for guidance in using a virtual serial port from a FTDI device connected by USB.
The RX/TX LED are directly connected to the FTDI output signals, so it possibly only means that stuff was received by the interface chip, but not the microcontroller. The A/B LED basically indicate a valid or invalid frame. Green = valid frame, red = invalid frame. If neither turn on then you have no valid data coming from the FTDI > SSC-32U’s microcontroller.
Alternatively, the SSC-32U also exposes a direct UART TTL (5 V DC) interface through the TX/RX/GND pins near the USB connector and a XBee-type socket. Please note you should only ever use one of those interfaces at any time (USB, UART, XBee) to prevent communication issues.
If your board provides a direct UART interface this may be a good alternative. If it happens that your board only runs at 3.3 V DC (likely) or lower voltage, you will need a level shifter between the two UART interfaces, such as this board. That’s one of my personal favourites since it even supports I2C level shifting (for bidirectional comm on a line)!
I think also that problem come from the driver on board. In fact, it is a hard work to develop a FTDI’s driver specified for a board without OS. Today, i decided to do the alternative method by using UART.
You could try and use the FTDI’s reference VCP driver, but it would not be an easy or trivial task. Definitely not worth the effort if making a device driver is not your goal.
All boards should include basic device drivers for all of their interfaces from the manufacturer. If your board has at least one free UART port that can support the appropriate baud rate (9600-115200), then that would certainly be much easier to work with.
