Hey Guys
I’m running into an issue with some C code on an LPC2148. I statically allocate memory for a float P[13][13], zero it and then add some values to the diagonal, eg. P[0][0],P[1][1],… Later in my program I go back and try and read elements of this array. Most of them are fine, but some of the values appear to have corrupted (they have absurdly high or low values). I have triple-checked my code and I’m not writing to any elements of P between the two stages mentioned. I’m wondering if I might have allocated memory beyond the capability of the microcontroller (32K). Can anybody please confirm what the chip does when this happens. Does this seem like standard behaviour, or would the chip reset?
Thanks in advance
Andrew
13 x 13 x 8 bytes (if that’s the floating point format you’re using) is 1,352 bytes.
I’d suggest looking at your compiler project settings.
Is this array a static global and not a local in some function?
Also, study the link loader’s map listing (you may have to turn this option on).
Floating point on a small RAM microprocessor is to be avoided, if at all possible, by using fixed point real numbers.
Hi stevech
Thanks for the suggestions. I disabled optimizations and debug symbols, which resulted in my code running correctly for longer longer. I then shifted some of the float arrays that were being dynamically allocated to global statics. These two changes improved my implementation significantly and my EKF seems to run pretty smoothly now. I guess that the problem was a result of the microcontroller running out of memory and overwriting previously allocated memory.
For future reference, is there a way to debug the LPC2148? I’d forgotten how amazing gdb is in helping solve memory allocation issues. I have received the LPC bootloader (http://www.sparkfun.com/products/714) and I’m very keen to try and get debugging up and running. Any tips would be greatly appreciated!
Cheers
Andrew
Sparkfun has a link to James Lynch’s [Arm Cross Development with Eclipse V3 (2005) on their [JTAG USB OCD Programmer page. I have a copy of Version 4 (2006) stored locally. I could post that but it would be better if someone could provide a link to an existing copy. Or even a newer one, if James created a later one.
That document is really dated now, but the explanation of how crt.s and your linker command file(s) are set up is pretty good - I still have not run across a better intro. Just skip forward until you get to the description of those files. Depending on your tool set, you may have a .pdf version of the manual for the ld linker somewhere. That is more readable than I expected it to be. You may be able to skip back and forth between those two documents and begin to get a picture of how your memory is set up.
Some tool sets (I’m thinking of Raisonance in particular) have a much more indirect structure to their linker command files that is not as easy to follow or puzzle out. You’d have to describe your setup to get more specific advice.
If you’re allocating a lot of variables on the stack (inside any function, including main), you might need to increase your stack size. Stack overflow would cause memory corruption for sure, and in a big way. But in my limited experience, that usually manifests as an un-handled exception (which makes it hard to diagnose).
You can indeed use gdb to debug your 2148 programs. Your target board must have a JTAG interface, and you need a JTAG adapter. There are instructions on the openOCD web site if you wind up going that route.](JTAG USB OCD Programmer/Debugger for ARM processors - PGM-07834 - SparkFun Electronics)](http://www.olimex.com/dev/pdf/ARM%20Cross%20Development%20with%20Eclipse%20version%203.pdf)
Hi hsutherl
Thanks for the really great info! I’m using the Ultimate IMU development board which, as far as I know, doesn’t have a JTAG breakout. So I therefore assume OCD debugging is not (easily) available. However, I’m going to keep this document on hand, as I’ve really liked developing with the LPC2148 and I suspect NXP will be my future micro of choice.
Cheers
Andrew
Yeah, my impression re the ultimate IMU is that your debug is pretty much limited to serial port output.
In chapter 24: RealMonitor of the 2148 user manual, the NXP authors mention a Keil / Arm tool called Angel that apparently was designed for background debug over the serial port. I sniffed around on the Arm site back in 2007 but didn’t see any hint that a free version was available. In fact I didn’t find much about it at all, which gave me the impression that it was obsolete even then.