I’m trying to establish communication with the Sparkfun LTE Breakout board (this one https://www.sparkfun.com/products/15087). It appears that the UART on the board does not function properly and I’m trying to determine why/what I’m doing wrong.
The board’s UART should have the TX pin held high (3.3v in this case) while waiting to transmit. But after the chip starts this is not the case.
The sequence is I press and hold the power button on the LTE board, the D0 (labeled “RX” but TX from the LTE board’s perspective) pin is 0V, wait 3 seconds, goes to 3.3V and then drops to 0V as soon as release the button.
The serial software/hardware switch is set to hardware and I am using the hardware pins (D0/D1).
In the video I made error and the scope didn’t show the voltage of the line, when the yellow line goes high it is definitely 3.3V.
The IOREF pin is connected to 3.3V.
5 volts comes in through the 5V line and the red LED lights up.
Everything shares a common ground.
I’ve also checked the the power and reset pins and these appear to be pulled up to .85V and 1.8V respectively. (Not sure why power is .84V but it is consistently within 20mV of that).
Any ideas/things to check/assistance would be greatly appreciated.
These really aren’t designed to be used without connecting them to an Arduino Uno, what you might try is powering the board via USB or the battery connector then connecting your FTDI to the FTDI header that’s in the upper left hand corner of the board. You will need to connect VCC, GND, RX and TX from your FTDI to that connector.
If that’s not working, try adding headers to the board then plug it into an Uno and follow the hookup guide to see if you can establish communication with the board using our example code.
Thanks. I tried with an Arduino Uno and the sample code and you’re right, it works! Although I’m baffled as to why that works but my earlier setup didn’t. I’ll try to test some other scenarios and see if I can strip it down to the minimum setup/pins required and find the exact difference and post a followup. For my application I need to be able to use this board without an Arduino Uno present, so I’ll need to isolate the exact difference to make it work for my use case.
The minimum set of wires/pins is: 5V for power, GND, IOREF for the level converter (I tested at 5v, but I’m hoping everything will work correctly with 3.3v), RX, TX and PWR_ON.
However, the length of the wires and any possible source of noise on them can and probably will be a problem. Using 6" wires directly from the shield to an Arduino seemed to work fairly reliably, but at about twice the length, or when connecting via breadboard, the serial data would begin to corrupt or initialization would fail (sometimes the Serial Passthrough program would not initialize the board, and other times it would but then I could see garbage come through in reply to some commands).
I suspect it does not like having any noise on the PWR_ON line as well. I tried leaving it floating and using the manual power button and was never able to make that work (but this could also be the timing, see below).
My oscilloscope was definitely messing it up also. Serial communication would work reliably using the Sparkfun test code and then connecting my scope up to one of the pins would cause it to fail to initialize.
After ripping apart the Sparkfun LTE library and trying many different things it appears that the initialization sequence that works reliably is to send it a series of alternating “AT\r” and “AT+IPR=115200\r” maybe 3 or 5 times, to see if the device is already powered on. If it is, and was earlier initialized properly, you should get responses. But, for the initial case when things are first powered up, you need to (after checking as above to verify that it’s not a warm reboot - because pulling on that power pin while it’s already running will mess things up) pull down on the power pin for 3.2 seconds and then with only a brief (if any) delay start sending commands as above. One or two may fail but then it should start responding. If the above sequence fails (e.g. due to line noise - long wires or poking at RX or TX with a probe), then for all intents and purposes from what I could tell the SARA-R4 is completely incommunicado until physically powered off and the above sequence is run correctly from the beginning. I’m honestly really surprised at how finicky this whole process was (maybe there is a good reason I’m not aware of or another factor I’m missing), but that sequence combined with the points above does seem to work.
The Sparkfun board itself only has the level shifter in between the board pins and the SARA-R4, and possibly that shifter is contributing to some of this; otherwise this appears to just be part of the fun of working with this chip. Or maybe just my ignorance of just how sensitive this chip is to any sort of noise. I guess I’m used to lower speed I2C devices that seem a lot more rugged and unaffected by line length.
Anyway, that’s what I came up with after messing with this for a while. Maybe it’ll help the next person who attempts a similar task.