Yes, I hadn't thought about the _dint, _eint being called during an interrupt. I'll have to fix that. But besides that it doesn't crash anymore.
Besides, the IE flag for TX interrupts is disabled, so I won't get empty interrupts… Thanks! --------------------------------------- Sergio Campamá sergiocamp...@gmail.com 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á <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 ------------------------------------------------------------------------------ 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
