ARM data abort caught at XXXX, Current Task 0x0C by ADEC

Legacy Open AT
1

Hi all,

I have this error, before when I was begining with OpenAT I got “Current Task 0x1F” o above which was my main procedure o others procedures and functions I wrote. I investigate a little and task 0x0C is related to V24, but I don’t know how to fix this problem, because I don’t use DATA MODE.

My application do this:

  • External equipmet send data to modem using custom AT command (V24 is related to custom command?)
  • Save data in ram on lists, if connection is lost, it keep adding items to list
  • Every time data is saved is analized to send critical alarms througt SMS
  • Send data to a server using TCP, delete items from a list if send OK

If I test at lab I don’t get this error, I disconnect antenna for minutes and reconnect then it keeps working like nothing happend. But if I take a trip on a car, it reboot frecuently with this backtrace captured.

I’m working with old Q64 (GPRS), not everybody worked with this modem, but your experience or someone of Sierra Wireless staff could understand the meaning of this error so I can understand where to begin. Thanks.

2

Hiya,

First thing I’m wondering is your power supply in the Car OK? These modules require a reasonable amount of power to operate - especially in bad signal areas.

Make sure that you can meet the burst power supply requirements for your module (check the Product Technical Spec). For example, the Q2686 requires up to 2A @4V for transmission (with a very short rise time).

ciao, Dave

3

Hi, thanks I’ll check power supply inside the car to discard this problem.

4

Hiya,

Can you get backtraces out of the module? That might give you an indication to which function in your application is causing the abort.

Could also be caused by the module disconnecting/reconnecting from the network when it is in the car and passes through a bad/low signal area.

Some more debug/logging is going to be required.

ciao, Dave

5

Hi davidc,

I have had tested power supply inside the car, It’s in normal operation, don’t get spikes lower than 3.2V.

I read bactraces, they are added as attachment. As you will see all rebooting captured where on task 0x0C, this is always happening. I don’t know why “unknown function” is displayed, maybe because it’s a task I didn’t wrote.

Like I said before, if task 0x0C is related to V24, maybe is related to AT COMMAND too, correct me if I’m wrong. I trace ATI, I don’t remmeber which level, but show me every AT command, even custom ones. Like a month, my rebooting problem was because external application was truncating the AT command or adding wrong characters to AT command, wrong parsing and the modem reboot. Traces where not captured, because AT command was unsuccessfully parsed, so AT can’t show me the parsing result in ATI traces. That’s what I thought.

And yesterday the problem finally happend at lab, but the traces can’t tell me nothing like I said before. It just happend after the AT COMMAND is sent by external application.

Best regards,
Backtraces 2014-01-28.txt (2.28 KB)

6

Hi,

A resume of captured traces in attachment file. I don’t have ATI traces activated like I said in my last post, but it never show because it’s possible that error happend before.

My custom AT Command is 5 parameters, total length between 90 to 100 bytes. I don’t know if it’s too long for AT Command api to parse, but which makes it weir, it could happend recently powered on or a day or two after.

Also captured all data sent by external application (not file attached) including the exactly moment when modem reboot, but as you will se in this Traces is that ADL_INIT_POWER_ON from adl_InitType_e is show, not ADL_INIT_REBOOT_FORM_EXCEPTION as expected.

This is my ATI9:

ati9
"DWL","V08b0e  ","","Sierra Wireless",50240,"040809 16:29","7eaf685b","00010000"
"FW","FW_SRC_747_8.WMP100F","R7.47.0.201202010317.Q64001","Sierra Wireless",2221420,"020112 03:17","31be8644","00020000"
"OAT","1.0.0.20140129170657","TEST","JLA",140744,"012914 17:07","2d14607d","00260000"
 -"Developer Studio","2.3.2.201310241753"
 -"Open AT Framework package","2.37.0.201202280640"
 -"Open AT OS Package","6.37.0.201202060950"
 -"Firmware Package","7.47.0.201202010317"
 -"Internet Library Package","5.43.0.201202100610"
 -"Security Plug-in Package","1.5.0.201108111447"
"ROM","400000"
"RAM","200000"
"DWLNAME","Q64001"

OK

Hope this information would help to analice this problem.

Best regards,
Trace - Posible AT command error.xlsx (11.3 KB)

7

Hi,

I haven’t solved this problem, I keep thinking that this problem is related to a parsing problem with long AT COMMANDS within the API.

So, what I did was to change receiving data using custom AT COMMAND to FCM over UART1, and it’s working and never giving the reset and backtrace again. Something I noticed is that traces can’t be used with the same port as FCM when DATA MODE is active, and if unsolicited AT command is sent, it is appended to the next time is in AT MODE.

8

Hiya,

Good to hear that you’ve got a work-around.

Just out of interest, how many parameters did you have in your AT command? I have a thought that there is a limit of 15 parameters - but I can’t put my finger on the doco at the moment.

ciao, Dave

9

Hi david,

It’s not to much parameters, it’s only 5 parameters but they are long enough to make me think of that.

Thanks for your help and your attencion.