If you want to use taht putchar in interrupts you had better save the
interrupt bit before dint and only eint if the interrupt bit was set before.
Based on the symptoms you have just described I would check the UCA0
interrupt bits. It is likely that you have a TX empty interrupt that is
getting triggered and either crashing or simply not clearing the TX IFG.
On Wed, Nov 16, 2011 at 10:35 AM, Sergio Campamá <scamp...@ing.puc.cl>wrote:
> 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
>
>
------------------------------------------------------------------------------
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
