ARM exception every 34 minutes

Legacy Open AT
1

Hi everyone,

I have a strange bug. I have a ARM exception every 34 minutes. I use a Q2686H with the new 6.61 os. Here is the backtrace :

ADS Bckt -------> ADS BACK TRACE <-------
ADS Bckt The function corresponding to this address : 0x70036002, is not in the .axf file
Trace SYS 1 Current OAT Task index : 0
Trace CUS4 1 ARM Data Abort at 0023D8A2, Current Task 0x1B
ADS Bckt -> memcpy : 0x0023D8A2
ADS Bckt -> Unresolved symbol : 0x000C4145

I take a look a all the memcpy in my code… I remove them all and I receive always the same error…

I check all the buffers, timers etc…

Have someone a method to resolve such situation?

Thanks in advance

Best regards,

gdt

2

Hello gdt,

Let me guess, you have a one second timer which calls the adl_cmdCreate() function every time. It is some kind of memory leakage problem int the “opic_api_oat.c” code. Please remove the adl_cmdCreate() from your code and give it a try.

I noticed this bug in beta version of 4.10, but i am totally angry that the final version still features this bug. I don’t use now fast cyclic adl_cmdCreate() procedures in my code, and now it looks stable. (tested for max. a week).

And another bug which i noticed today, when i try to send something on the I2C bus the module just stops and the game is over. No error messages no watchdog reset, no exception reset. I say what the hell? I guess the problem is that i tried it on the starter kit, and it has no pull-ups on the I2C pins. But it can’t be handled in a good manner in 2006?

Best Regards,

tom

3

I am speechless.

4

Hi Tom & Jan,

I use adl_atCmdCreate to update adc values in my ram registry every second (tom you are right !) and every 30 seconds to update network operator and so. I make a test now without calling adl_atCmdCreate in a timer and I post the result.

Many thanks !!!

Best regards,

gdt

5

Hi again,

We are also updating values about every 30 seconds… So, if the problem still exists even when not using a 1 second timer, then we maybe could have the crash just later, like in 30*34 minutes = about 17 hrs… Then I really hope our battery doesn’t last that long…

Best Regards,
Jan

6

No more reset…

Thanks tom !!!

Have a great week-end and best regards,

gdt

7

Hi,

does anyone knows if this happens also in the 6.60 firmware-version with OpenAt 4.40? Could it also happens during reading the ports with the adl_ioReadingSingle - function?

Tom wrote: “I don’t use now fast cyclic adl_cmdCreate() procedures in my code, and now it looks stable. (tested for max. a week).” In which cycle do you use commands like CREG, ADC, CMGR…?

A year after the first firmware version there should not be such mistakes anymore…

Best regards,

Marcus.[/code]
[/quote]

8

Hello marcus,

The Open AT 4.00 with OS 6.60 has not this bug. But the WIP libary was quite unstable on OS 6.60 for me.

AT+CREG,AT+CGREG: you can safely monitor this values through the unsolicited messages (+CREG:, +CGREG:) In this case, you are informod instantly about the network registration changes.

AT+CMGR: Use the SMS ADL api to handle SMS messages.

AT+ADC, CSQ, … : I don’t know what to do with this command.

I will run some test about this problem, and i will write down my experienes. Maybe somehow we can by-pass this.

Update:
I could not find a solution. :confused:

Best Regards,

tom

9

I think we just hit this problem too.

I downloaded SDK 4.11 from our distributor only to find that neither firmware nor open at adl libraries has been changed since 4.10.

In the only release note document included this problem is not described as a known problem.

Does ANYONE know when this will actually be fixed?

10

Hi everyone,

Bad news, Wavecom said that :

" We have created the TT anomaly CUS36968 for this problem.
It will be corrected in the 6.62 OS which will be released in March 2007."

No comment…

Best regards and Merry Christmas,

gdt

11

If it’s to be released in March 2007, then it should be out for beta testing by now too.
Can anyone confirm that they have actually fixed this problem?

Judging by other posts in this thread it is likely that a new SDK is needed with updated OAT/ADL libraries.

12

So what does that mean?? :angry:

What is the “TT anomaly CUS36968”?

Does this mean that Wavecom have identified the bug?

If so, what , exactly, causes it - and how to avoid it?
What versions are affected?

A search on the whole site (and the FAQ) gives no results. :angry:

13

It’s the bug identifier. Wavecom has release the 4.12 version with the patch for this command. Apparently, not other modifications was introduced in this release.

Best regards,

gdt

14

Is 4.12 for 6.62 or is it still for 6.61?

15

still for 6.61. My distributor tells me that the next release will come at the end of march.

Best regards,

gdt

16

Got my hands on 4.12 now and judging from the description in the release notes it’s adl_atCmdCreate that is not releasing allocated memory after processing. (the notes say something about after a number of calls, the heap memory gets filled and module is restarted)

Quite stupid bug that should have been caught long before 4.1x was released at all.

17

“TT anomaly CUS36968” means that they’ve tracked the issue under this ID and to really know if they have corrected it in the next firmware you have to read carefully the FW or OS release note and see if this tracker is mentionned in the corrected issue paragraph!!

18

I don’t know about ADC, but you can enable unsolicited +CSQ: with the AT+CCED command…

But, as noted here wavecom.com/modules/movie/sc … php?t=1171 it would really be better if Wavecom provided a proper API for this stuff - rather than all this messing about with AT commands… :frowning:

19

Well, you’re right, but on the other hand, that would double the firmware size, and the work… everything would be implemented twice, once in ADL and once in AT interface.
I’d better like Wavecom spending their time fixing bugs. :unamused:

20

I don’t think so - I think ADL uses the AT interface?

You do have a point there!

And they need to spend a lot of effort on the documentation!