> > Am 15.11.2011 00:30, schrieb Sergio Campamá: >> The weird thing is I have like 8kb of RAM, but the firmware crashes on >> printf statements. msp430-size tells me that data+bss is 2666, so I believe >> I have enough RAM. > > good. > > the output goes directly to the serial port or to a buffer? if it is a > buffer, is there a size check? >
The output is direct, no buffers. >> We're using Z1 nodes, and the JTAG connector is somewhat complex to access >> (they charge 16 bucks for every connector, Im looking to make one myself >> right now) so access to the PC to see where it stopped is limited as of >> now. The app works properly and never crashes if we dont use printf, so I >> dont know what could be happening.. > > memory usage and timing issues are the first things i'd look at. > As soon as I get JTAG access I'll look into that >> Although, I am using TimerA to generate 1 ms interrupts using the external >> 32768 crystal to keep an internal clock... is printf friendly with such >> kind (rapid) of interrupts? > > the interrupt handlers are short and not using printf? > > using printf from interrupts may cause problems, as printf takes a lot > of CPU cycles (and stack memory). > > older printf implementations are also not reentrant (the latest is, but > your putchar may not be). > no, I don't call printf from interrupts... >> Another related question. What really happens when the memory gets >> overwritten? > > a typical problem is when the stack overlays variables and the variables > are altered. so they alter memory that currently is also used as stack > and therefore it may corrupt return addresses. similarly such a deep > stack could also overwrite function pointer variables. > > an other common error is a buffer or array in the middle of all other > variables that gets overrun. so variables before or after that buffer > get overwritten. > Is there any technique to check the status of ram? as in a full dump? >> Why does the msp430 crashes instead of going back to the start >> of the program? Does the PC get stuck? Does it generate an interruption? > > There are a few cases: > a) PC is offset and executing invalid or not the intended instructions. > b) PC points to other memory e.g. peripherals, RAM not containing code. > see case a) > c) "bis.w LPMx, SR" is accidentally executing, putting the CPU to sleep. > higher LPM modes also stop other clocks. > d) interrupts occurring at a faster rate than the processing takes > e) not clearing the interrupt flag (IFG) -> interrupt is constantly > restarted > f) using EINT in interrupt handlers -> nested interrupts are possible > which may use a lot of stack memory -> overwrites > g) recursive function calls -> stack -> overwrites similar to f). > ... > > newer MSP430 series detect some of the conditions above (e.g. > instruction fetch in peripheral area, invalid instructions) and reset. > but usually it just keeps executing. > an other common way to recover is using the hardware watchdog (WDT). > > when the CPU is executing "random" instructions a lot of other things > may happen, such as reconfiguring ports and peripherals. > > > but it's not always that complicated, sometimes it's just loops with > wrong exit conditions ;-) or a printf of a string (char *) that that > points to some other place than intended. and then it keeps printing > hundreds of bytes until a string terminating zero byte is hit. > > also to consider are race conditions or waiting for events that never > happen or occurred faster than expected. e.g. > - polling for a hardware condition when the peripheral is stopped > - interrupt handlers and foreground functions accessing the same > complex data at the same time without appropriate protection > (leading to inconsistent data) > - clearing and then waiting for a flag from the hardware (e.g. IFGs) > but the hardware already had set the flag before it was cleared. > - setting up a compare with the timer to a time that is already passed > (the timer interrupt will be one timer round later than expected) > - ... > these are not crashes but may lead to unexpected behavior. > I'll check on these suggestions… But I can't really see it until I get my hands on JTAG… Thanks!! > chris > > ------------------------------------------------------------------------------ > RSA(R) Conference 2012 > Save $700 by Nov 18 > Register now > http://p.sf.net/sfu/rsa-sfdev2dev1 > _______________________________________________ > Mspgcc-users mailing list > Mspgcc-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/mspgcc-users ------------------------------------------------------------------------------ RSA(R) Conference 2012 Save $700 by Nov 18 Register now http://p.sf.net/sfu/rsa-sfdev2dev1 _______________________________________________ Mspgcc-users mailing list Mspgcc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mspgcc-users
