something like READ_SR() & GIE
From cPhone On Nov 16, 2011, at 6:28 PM, Sergio Campamá <scamp...@ing.puc.cl> wrote: > Umm, what would be the proper way to check the GIE bit from the SR? > > Something like _BIS_SR(GIE), but not to set, just to read the SR... > --------------------------------------- > 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 ------------------------------------------------------------------------------ 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
