On Tue, Sep 4, 2012 at 11:52 AM, JMGross <msp...@grossibaer.de> wrote: > ----- Ursprüngliche Nachricht ----- >>True, but that won't matter. Compilers do not usually track the state >>of status bits over a longer range than one instruction pattern. > > There's more in the status register than just the status bits. > There are the LPM bits too. Besides CPUOFF, which is of > course never set when the CPU is running, there is the control > for XT1 or DCO. And in 3x/5x family, one of them controls the FLL. > Just overwriting the status register may unintendedly reactivate the > FLL, that might have been deactivated inside the atomic block, > with desastrous results. And the others might have impact on > current consumption. > Well, one could declare it as a coding bug to deactivate the FLL inside > an atomic block, but I prefer not creating dependencies where I can avoid it. > And if the atomic block is a timing calibration function, it might be > necessary. > > How does the latest MCPGCC handle this on funcitons with critical > attribute?
The "critical" function attribute in mspgcc saves and restores the entire status register. Any changes within the function are discarded. Use of "biX_status_register_on_exit()" may or may not work; I haven't tried it, and wouldn't count on it if it did. As you point out, there are reasons why somebody might want to control SCG0, and the fact that __set_interrupt_status() might overwrite that is a concern. When implementing the intrinsic I asked on E2E how it behaved on other platforms, and was told it restored all the bits. I considered alternatives that would save only GIE, but decided that doing so wasn't worth the hassle and loss in performance and compatibility. Besides, a benefit of explicitly using __set_interrupt_status() and __get_interrupt_status() is that the application gets full control of what bits are restored. Any intentional changes to the live status register can be replicated in the saved state before restoring it. (Though really, if you're going to play those games, you should probably use __read_status_register() and __write_status_register() instead; it's unfortunate that IAR and CCS chose a name that implies only the interrupt status is manipulated.) In the MSP430 infrastructure environment I'm developing (both standalone and for FreeRTOS) I allow the application to control what bits are cleared on LPM exit, and ensure any infrastructure routines such as ISRs that manipulate the status register don't clear SCG0 when they shouldn't. This was specifically a result of the severity of the UCS errata in the 5xx family and the importance of controlling FLL behavior via SCG0 to avoid them. Peter ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ _______________________________________________ Mspgcc-users mailing list Mspgcc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mspgcc-users
