Handling URC (Unsolicited Result Code) in Hayes AT Command

URC is the message that is sent from the ME (Mobile Equipment, eg. GSM/GPRS/CDMA modem) that’s not the result of the AT command.

Here’s some examples: RING is sent when the modem is called, CONNECTED is sent when the modem answer the call, or +CNMI is sent when modem received new SMS. You can think of URC as modem’s soft interrupt.

So, what’s the problem with the URC ? Unless you haven’t programmed any of application that deals with the modem directly, you will notice that URC sometimes destroy your parser state machine when it fires in middle of executing AT command.

Here’s the illustration of the URC problem:

application>AT+CMGL=4 # List all of SMS inside the ME
ME> RING # Incoming call
ME> OK # There's no SMS inside the ME
ME> RING # Incoming call


The RING between AT+CMGL and OK is happenned because the AT command hasn’t reach the serial port, while the incoming call is received. This may break the AT command parser. But there’s a way to help it.

Bad Example of Interrupt Handling

In life, you need two examples: good one, and bad one. Here’s one of my bad design of interrupt handling.

The purpose of the firmware was to read a line (CR/LF terminated characters) from serial port, then parse it. Actually, I tried to port my simple AT handler from Java into C (AVR-GCC). It works, and as you can see, this program runs okay under x86 PC, but not under AVR with 8Mhz xtal.

Here’s the actual problem:

Tail-Chaining ARM Cortex-M0 Interrupts

Building ARM Cortex-M0 bootloader seems like a bit more difficult that what I’ve imagined.

Here’s the first challenge: the ARM Cortex-M0 interrupt vector table is not relocate-able. Hence, if we put our bootloader into ARM Cortex-M0, we need to find some way to chain the bootloader’s interrupt vector to user’s interrupt vector.