How about this then?
int putchar(int character)
{
void uart_a1_send_char(uint8_t character)
{
uint8_t should_enable = 0;
if(__read_status_register() & GIE)
{
should_enable = 1;
__dint();
}
while(! (UC1IFG & UCA1TXIFG));
UC1IFG &= ~UCA1TXIFG;
UCA1TXBUF = character;
if(should_enable)
__eint();
}
}
Although I feel it a little cluttered for it to run on every single character
of every string printf'ed. If I just make sure not to call it from an
interrupt, I guess it is unnecessary
---------------------------------------
Sergio Campamá
[email protected]
On Nov 16, 2011, at 8:29 PM, Crazy Casta wrote:
> 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á <[email protected]>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á <[email protected]>
>> 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
>>>> [email protected]
>>>> 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
>> [email protected]
>> 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
> [email protected]
> 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
[email protected]
https://lists.sourceforge.net/lists/listinfo/mspgcc-users
