AT Firmare hangs after wrong baudrate

[Mikael Grah]

Hi,

I discovered a strange “bug” with one of our products, and I was just curious to hear if this is “as designed” or if it’s an unfortunate feature. And, it may help someone else that runs into the same issue (Google couldn’t help me find the answer).

We are developing a product based on the EU868 mDot. As the master processor in the design is quite weak, we’re using a serial communication with 19200 baud between the processor and the mDot, with the AT command Firmware on the mDot.

During boot, the processor will try to communicate with the mDot @ 19200 baud (8N1). If there is no response, the processor will switch to 115200 baud and try to reconfigure the mDot to 19200 baud before continuing.

We’ve been using this approach with ~25 devices this far, all “older” mDots with AT Firmware 2.x. and it’s been working fine.

In the newest batch, the mDots are delivered with AT Firmware 3.1.1. When starting up at 19200 baud with the mDot configured to 115200 baud, the commands to reconfigure the mDot don’t work. After some debugging it turned out that we had to power cycle the modem (to know that it was reset) before it started to respond. I then managed to repeat the process using a standalone mDot with the dev kit connected to the USB port on my PC (using a terminal to send AT commands).

Earlier, when trying to reconfigure the modem after failing to communicate at 19200 the mDot will respond well to the change of baudrate. I can see in the log that sending AT+IPR=19200 CR LF will be echoed back, including the CR LF, but with newer firmare (both 3.1.1 and 3.2.1), the command is echoed, but the CR LS as well as the response from the modem (ERROR/OK) is missing. The same goes for further commands we send (AT&W – pause – ATZ).

As I said above, a power cycling of the mDot right before trying to reconfigure it solves our problem.

Is this the way it was intended? I assume that some of the stuff sent over 19200 baud messed with a state or something in the AT Firmware…?

Thank you,
Mikael

[Mikael Grah]

OK, so the description above is 100% repeatable with xDot and AT firmware 3.2.1, as far as I can tell.

I did the following:

Boot up (USB to PC). Type the following commands manually @19200 baud:
+++\r\n
at\r\n

Of course, since the xDot is configured @115200 baud, I get garbage back. Switch to 115200 baud on the PC and send the following:
+++\r\n
at\r\n

The modem responds with the echo characters, excluding the \r\n:
+++at

The normal response would be (communicating @115200 baud from the start):
+++
Command not found!
ERROR
at
OK

This behavior is the same with 3.1.1 and 3.2.1 with both mDot and xDot.

Now, this is an issue for our design, as the “next generation” hardware will not be able to switch off the power of the modem.

Is there any way to get the Dots to “exit” the mode that they’re in? Like an Abort sequence?

[Jason Reiss]

This is a known issue since 3.1.0
https://os.mbed.com/teams/MultiTech/wiki/Dot-firmware-change-log

Reset is the only way to recover the device.

Do you have the debug pins wired to the host MCU?

A serial break on the debug port should reset the device.

[Jason Reiss]

The firmware posted for beta has an updated mbed-os version 5.13.4 and do not appear to have this issue. Our next release will use an updated mbed-os.

https://github.com/MultiTechSystems/Dot-AT-Firmware-beta

[Mikael Grah]

OK, great, thank you!

I’ll test with the latest firmware and see how it responds. This isn’t a major issue for us, but it’s good to know the reason for the behavior.

The debug pins are connected to an external debug port (for PC use). 🙂

[Author]

Posts