Communication port C does not transmit data.
Our application sends and receives data through ports A and C but sometimes the C does not transmit anything, when this happens we turn off and on again and sometimes it works and other times it does not work. What can be happening? It seems that it did not boot well at boot time.
We have checked the outputs of the module and when it does not work both the TX and the RX output are at a permanent high level when the port is open, but there are no changes when our program sends data.
Checking the problem we have observed that when the GPIO 100 output does not work it is configured as usb.OTG1_OC, if we configure it as uart3_RX_DATA the port is already working, so this is going to be the problem. The list is where can we establish that this GPIO 100 output is set to port C? Can it be done through registry?
If you are trying to set pinmux to select pin as uart3_RX_DATA, then I believe you want to use the config block tool. You can set the pin type, and then save the config so it persists across re-boot. You can also do the same thing in E-boot, but the config block tool is easier to use.
Dear @Tecael
I was able to reproduce your issue here. I investigated the reason and found a bug in our registry settings:
The USB OTG driver reconfigures the pin SODIMM 21:
[HKLM\Drivers\BuiltIn\USBOTG\Hcd\Pinout_Default]
"colibripin_21" = "altfn=1"
If this configuration happens after the UART3 driver is loaded, SODIMM 21 will be in a wrong state and cannot transmit any data.
The solution is simple: just delete the entry colibripin_21 from the registry, then save the registry.
I added this to our bug tracking system. I also want to verify that this change does not have any negative impact on the USB OTG functionality, but it will take a while.
Regards, Andy
