My meaning was the USB2Serial communication between Renfell USB host IoT card and our wearable FTDI still showed the frequent TTY break error in ftdi_sio driver level.
In summary,
Renfell IoT card recognition issue : solved by GPIO2 control
USB2Serial communication error between our wearable and MangOH b/d USB( USB Host connector or Renfell USB host IoT card) still exists.
Asyal,
can you let me know how to program USB3503 register? The preferred way is by I2C port(I2C1 on the schematic) configuration via device tree and programming it in the device driver.
Then can you let me know what I2C port of mdm9607 is mapped to I2C1 of wp7702?
In mdm9607 device tree, only I2C4 is configured @78b8000 IO address. Assuming it is mapped to I2C1 of wp7702, I tried to register TCA9546A I2C mux/USB3503 device as I2C4 devices and programmed it through that IO address. However it seems the assumption is wrong.
I could manage to program TCA9546A I2C mux/USB3503 register by writing I2C driver and the proper device tree change and disable the port 1-2 and enable download streaming charging etc. However the issue was still seen.
I’ve got MangOH Green b/d and tested it with both DC adapter power and USB power source. The USB2Serial communication work perfectly with our wearable device!
Definitely the issue only exists in MangOH Red but we don’t know the root cause…
Even with TCA programming, the issue - intermittent but iwith high frequency TTY_BREAK error was still seen. By the way the same FW works OK in MangOH Green too. I suspect the subtle signal integrity error on the USB data path though TCA to WP7702 HSIC_DATA. Anyway we will design the custom PCB by referencing MangOH Green instead.