Problem: A RAK3272-SiP module would not accept AT commands when connected to a prototype product microprocessor board. Any AT command sent to the module would either get no response, or sometimes the response would be a single character “A”. The RAK3272-SiP responded correctly when attached to a PC using an USB-to-serial adapter. An alternate brand of LoRa module, when connected to the prototype board, worked flawlessly using the same PIC firmware.
Hardware: RAK3272-SiP modules, and a prototype product using a PIC24FJxxGAxxx microprocessor. Also a FTDI-based USB-to-serial gizmo for basic testing on a PC.
RAK3272-SiP F/W: RAK3272-SiP RUI 4.0.6 (also tried RUI_4.0.5, and RAK3172-E)
Root Cause: As part of the PIC boot-up routine, the UART peripheral is initialized. This sequence is Disable the UART peripheral > Configure the peripheral > Enable the UART peripheral > Enable UART Xmit > Enable UART Receive. This sequence causes the UART MOSI to momentarily be pulled low. This puts the RAK3272 module into some weird, undefined, state where it will not accept AT commands.
Corrective Action: After the UART intialization, the RAK3272-SiP MUST have a H/W reset by pulling RST low (J3-P3). The reset sequence is: RST low for 50ms > RST high > wait 500ms for module to complete sending out its boot-up message. (At 9600bps, the boot message takes about 375ms.)
I wasted a lot of time figuring this out. I hope this note will help someone else. And, FWIW, a Siglent SDS1104X-U with built-in serial decode is an excellent, inexpensive scope for debugging this type of problem.