UART2 Receiving strange characters

[VincentChou1z]

Hi!  

I would like to ask whether anyone has experience to receive strange "^@" to corrupt the UART data from UART2 when UART2 is enabled.  We tried different configuration option on UART2 and the target device operates at 19200 baud rate and 8N1 mode.  However, we could not observe "^@" from PC terminal if the device is connected to the PC directly.  If you have similar experience, please share how you solve this issue.  

Vincent

[AlanLevy]

The _MX53_PAD_DATA macros for UART2 are correct - we are using them unchanged on our hardware. The 2.8V RX line is probably significant, it appears you have a hardware problem.

[VincentChou1z]

Hi! We did try to try a few combination of wiring for experimental purpose. 

1. First we tried to connect the board to the device with an LA attached and we could see that Logic Analyzer could capture the data correctly but our board will get some control characters sometimes. 
2. Secondly we wire the PC com port to the board to simulate the device.  This time the board could read the data correctly every time. 
3. We use a PC to connect to the device and the PC could receive the data correctly without problem. 

The scenario one suggests that the strange character may be the result of the error generated by the code we developed.  The second scenario also indicates the code could receive the data from PC without problem.  The third scenario indicates that device may be correct.  Nevertheless, the Logic Analyzer could recognize the data from the device without problem. 

We also observe a strange phenomenon in the process.  In the UART2 RX line, the initial voltage is pulled to 2.8V instead of 3.3V on UART2 but the TX line maintains a 3.3V level.  We also measure the voltage level on UART4 and both TX and RX are configured at 3.3V when booted up. 

I also checked iomux_mx53.h and discovered some strange configuration on UART2 PAD.

#define _MX53_PAD_PATA_DMARQ__UART2_TXD_MUX     IOMUX_PAD(0x5F8, 0x278, 3, 0x0, 0, 0)

#define _MX53_PAD_PATA_BUFFER_EN__UART2_RXD_MUX    IOMUX_PAD(0x5FC, 0x27C, 3, 0x880, 3, 0)

The fourth parameters of TXD and RXD are different.  One is 0x0 and the other is 0x880.  Do you think this is something we need to modify this time as well?

Vincent

[AlanLevy]

I could only guess. I suggest you start by connecting a PC to the serial link and use a suitable program to dump out the received character values in hex. If that doesn't help, you'll have to use a storage scope and/or a logic analyser to look at the serial link and find out what's actually happening on the wire.

[VincentChou1z]

Hi! Alan,

If "^@" represents NULL (\0), does that mean the UART could not recognize the value received from the RX and interprets it as a NULL and put it into the memory buffer?  Or is it the value sent from RX signal line?

Also, could you explain a little bit about the two situation you described?  We suppose to receive data from the device with a fixed length.  For instance, if we would receive the data like "0A-1B-2C-3D-4E-5F" from the device as normal data, however, sometimes we get "0A-1B-^@-3D-4E-5F" as erroneous data.  We also check the UART2 RX line and it does not connect to any other net.  Does that mean the erroneous data is sent by the external device, not by our program?  

Because the error occurs among the data packets, do you think the signal on the RX line been dragged to a level too low to be recognized?  Why does the PC terminal recognize the data still?

Vincent

[AlanLevy]

"^@" is normally used to represent a NULL (\0) character. Either something is sending NULLs by mistake, or just possibly the transmitting UART is generating break levels that are being interpreted as NULLs by the receiver.