Von: Sergio Campamá
> I'm developing an app that uses heavily printf for debugging... Now, when
> activated (through a DEBUG macro), the app crashes very rapidly, being
> random the moment it crashes (almost always it crashes mid sentence)...
One thing I discovered with printf is that the compiler puts the parameters on
stack,
but when optimization is on, it does not remove them from stack after the call.
This is only done at the end of the current programming block.
(e.g. loop exit or function return).
So all parameters pile up on the stack.
This caused serieous problems on the 1232 with only 256 bytes ram.
My solution to this was to enclose all printfs by a do{}while(0);
#define PRINTF(x) do {printf(x);} while(0);
>__dint();
> while(! (UC0IFG & UCA0TXIFG));
> UCA0TXBUF =3D character;
> UC0IFG &=3D ~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...
The nop is added after the dint to ensure that no interrupt occurs after the
first
instruction after the dint. THis is possible because of the pipelining in the
MSP core.
(when the dint is executed, the next isntruction is already fetched and an
interrupt
might already have been accepted).
However, it is not necessary to clear UCA0TXIFG, as it is automatically cleared
when writing to UCY0TXBUF, except if the output shift AND TXBUF have been empty.
(in this case, TXBUF is immediately forwarded to the shift register and empty
again).
In fact, manually clearing it can be dangerous:
If the USCI was idle, the write to TXBUF clears TXIFG, then its content is
moved to
the output and TXIFG is set again. If you manually clear it now, it will stay
cleared
forever (well, until you write to TXBUF even if TXIFG is clear, or reset the
USCI)
This only happens if between the write to TXBUF and the clear of TXIFG a tx bit
clock tick happens. How often this happens depends on the ratio of MCLK and
the baudrate. And on the likeliness that an interrupt of any kind happens
between the two instructions.
By blocking the interrupts, you removed one possible source for a lockup,
but it is still possible that between the two instructions a tick happens.
Just much less likely than before.
JMGross
------------------------------------------------------------------------------
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
