UART: strange garbage character

[Dot]

Hi

I am working on an LTE/WCDMA/GSM breakout board using SIMCOM's SIM7100E module. It's an upgrade from an older module (SIM5320) and there's difference between the two in voltage levels. I built the new board, tested it and everything is OK apart from one little weird thing happening on UART's Tx/Rx line. To make things clear, please find attached a block diagram of the older system emphasizing the UART interface circuitry.

The older board (SIM5320) was working on 2.8V level, but SIM7100E works on 1.8V level, so I had to add a buffer stage (buffer, non-inverting, open drain outputs) pulled up to 1.8V from module's side. Please find attached a block diagram of this modified interface. I wrote a small code to test Tx and Rx lines and did some debugging and here's what I found:

1. Tx is perfectly normal. I can send AT commands from microcontroller and SIM7100E behaves accordingly.
2. Rx is little weird. When microcontroller starts reading, a garbage character is always first received as shown in attached image. After that, when sending AT commands, module responds normally and UART buffer overwrites this garbage character and no more garbage is received. See attached image for a typical response to (AT+NETOPEN) command.

I debugged three other samples and they've shown the same behavior, except one which reads a slightly different garbage character (0xF8, 'ø' in extended ascii). I have to mention that 2.8V source, as shown in circuit, is an programmable output from SIM7100E and it's normally OFF when module is powered up. An AT commands has to be sent in order to make it ON. The strange thing is that even when this output is OFF, which puts Q2 BJT in cut-off mode, this garbage character is still received, which makes me even more confused about why this would happen in the first place.

I would highly appreciate your debugging thoughts.

Thanks

[rs20]

I don't know the full answer, but hint:

0xFC is 0b11111100 in binary; and 0xF8 is 0b11111000 in binary. In other words, you're seeing a string of 1's, followed by 0's. This suggests that some voltage (power rail?) somewhere is taking a while to reach the right value (slightly differing between samples), and you're reading in spurious 1's in the mean time.

Are you commencing these tests immediately after the devices are being powered up? What's happening immediately before the garbage character is received? Trying reducing the number of things happening immediately before testing communication.

[Dot]

Nothing happens before reading UART. I just send a command to open 2.8V from USB port. Actually, I provided a long delay (1 minute and a half) before starting to read UART, but the problem persists.

I just changed the host board and the problem seems to be non-existent anymore! 3.3V source is provided from a 4.2V SMPS that's fed to a DC-to-DC that gives 3.3V. On the first host board, I tried with a SIM5320 module, wrote a code, debugged it and there was no garbage character. I removed buffer IC from SIM7100E breakout board, making UART interface between it and microcontroller open, and didn't receive any garbage.

Since changing the host board made a difference, then the problem seems to be not related to SIM7100E board. Still, there's something weird given that SIM5320 didn't receive this garbage on the problematic host board. It could be from 3.3V, 2.8V or 1.8V, or a combination of other things. There's definitely something that randomly switches as soon as microcontroller starts reading UART line, which gives the 0xFC and 0xF8 combinations.

What do you think?

[dfmischler]

What do you think?

I think that if you are only building one then take the shortcut you are on (i.e. it's that board so ignore it).  But if you plan to deploy a bunch of these then make the software deal with it in a robust way or it will rear its ugly head (again) when you least expect it.