Ok, I got it working now...
With the interrupt disable/enable in putchar, as in the following code, the
app never crashes
__dint();
while(! (UC0IFG & UCA0TXIFG));
UCA0TXBUF = character;
UC0IFG &= ~UCA0TXIFG;
__eint();
I think with this, printf CAN be called from interrupts... Looking at the
generated assembly, this only adds 3 instructions in total, eint, dint and
a nop...
On Tue, Nov 15, 2011 at 4:43 PM, Sergio Campamá <scamp...@ing.puc.cl> wrote:
> >
> > 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
>
>
------------------------------------------------------------------------------
All the data continuously generated in your IT infrastructure
contains a definitive record of customers, application performance,
security threats, fraudulent activity, and more. Splunk takes this
data and makes sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-novd2d
_______________________________________________
Mspgcc-users mailing list
Mspgcc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mspgcc-users
