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? > 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. > 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). > 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. > 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. 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
