CPU Hangs with led blinking


I’m coding an app on FastTrack XTend + CGPS module which sample gps position every 5 seconds and stores it in an array of 20 positions objects. Every 20 objects i store my struct array into A&D storage in a block.
The storing procedure is:

  • erase block
  • write new block
  • finalize it
  • recompact

I do a recompact procedure every new block writing because i have total 500 block of 20 positions, every position struct is 52 byte size, so 52 * 20 * 500 / 1024 = 508 KB, i need to do recompact to erase completely the old block before reallocating new in a circular queue of 500 blocks.
So, i don’t know if this is the correct procedure to work with A&D storage, because when the app is running since 8-10 hours the cpu hangs (not resets) and the gsm led (red) starts blinking with CGPS led (yellow) at the same time.
I need to reflash firmware + eeprom and erase openat app, flash objects and a&d with DWLWin every time this situation occurs to get back it working again.
What’s wrong ? There’s another way to delete blocks without doing recompact every time ?



You may be repeating the recompact too often ,
I suggest before writing something new into the A&D Storage check how much free space you
have , and if it’s below a certain limit then do the recompact .



IIRC, your can query the A&D system, and there’s an indication of whether a recompact is required :question:


Another thought: the recompact process can take a long time - you’re not waiting for it in a while loop (or similar), are you…?

See: https://forum.sierrawireless.com/t/faq-forum-wiki/3491/1

Also: viewtopic.php?f=7&t=3766&hilit=exhaustive&start=15#p18220


I’m waiting for recompacting process, when it’s done i set a boolean and my functions to store/write on A&D can make these operations, if the boolean is not true (the A&D is still recompacting) i do nothing into these r/w functions. So the process is protected. The strange thing is the kind of cpu hang… red and yellow leds (GSM + CGPS) both blinking at same time, no more serial I/O, reflashing firmware and eeprom needed to get back work correctly. Tested on 2 fasttrack xtend, same kind of cpu hang. The watchdog isn’t excluded. It seems to be a ‘write into protected area’…maybe ?

Note: my app is event-driven, very reduced use of loops, timers with static counters instead of loops.


How, exactly?

Without seeing your code, it’s impossible to know what that might mean on the yellow LED!
However, the GSM LED can appear to be “blinking” when the unit is crashing & restarting continuously - it goes off when the unit crashes, then comes on steady when it restarts, then goes off when it crashes, etc…

What, exactly, do you mean by that?

Why do you think that?

Open-AT is inherently event-driven!

What, exactly, do you mean by that?
It only takes one loop to hang and trigger the watchdog…!


My struct (52 bytes):

#define RAMPOS 20
typedef struct
	adl_rtcTime_t	DateTime;
	double 			Latitude;
	double 			Longitude;
	double			Speed;
	ascii			LatLonDirection[2];
	u8				MovementTypeStatus;

GpsPos Positions[GPS_RAMPOS_MAX];

Storing gps positions on ram, when recompact process is done and positions array index = 20 i store new block to a&d (if recompact is finished). simple.

Leds are not important thing, the strange thing is the serial i/o disabled, reflashing firmware is needed.

I mean that if i do


the app restarts normally. So watchdog is working correctly.

I don’t know…

I use timers instead of loops and i haven’t any loop that can trigger watchdog, believe me.

To conclude, my app doesn’t restarts, it hangs cpu and destroy serial I/O, after a long time of execution.


You still haven’t said how, exactly, you “wait for the recompacting pocess”.

How do you determine that it’s finished?

If that’s true, it sounds like you have a “hole” in one of your state machines where it can get stuck.

Have you added plenty of TRACEs to show you what’s happening…?


ADL_AD_EVENT_RECOMPACT_DONE in my storage event handler of course.

I’ve rewrite my code, no more recompact process every 20 positions(too much times). Thanks however.