----- Ursprüngliche Nachricht ----- Von: Peter Bigot Gesendet am: 12 Dez 2011 15:22:41
On Mon, Dec 12, 2011 at 7:49 AM, JMGross <msp...@grossibaer.de> wrote: >> I only know that the code above would have exposed the problem >> on the 1232 I worked on ~6 years ago. >> (interestingly, this never appeared in the 1232 errata sheet) >> Since then, all my operations on SR include a following NOP unless >> the next operation is known to be not critical. So I never checked >> again. >> And I don't have one of the old 1232 anymore. >> However, on many MSPs (if not all), a breakpoint on the MOV would >> be triggered before LPM is entered. >> Maybe the LMP mechanism does discard the already fetched >> instruction then. > Thanks. As I've said, I don't consider the evidence of a breakpoint > firing prior to LPM to be relevant to anything. The instruction would > have to be re-fetched after wakeup anyway, given intervening interrupt > processing. Well, from a compiler view it isn't a problem. >From a user view, it is. I got many issues where people were setting a BP after LPM entry and inside ht eISR and were thinking their code was not firing an interurpt at all because the BP after LPM was hit before the ISR one. If you know this, all is well, But many people are just ignorant of this. It is possible that the re-fetching did not take place in early silicon. Enterign LPM is just stopping MCLK, and why should an instruction be re-fetched when the MCLK speed changes (to 0Hz and back)? Well, the logical issues are a reson, but maybe nobofy was thinking of them when implementing it first. > As you note, there are no CPU errata (per the April 2011 update) for > the MSP430F1232 that would explain the behavior you remember. Right, but even my original errata sheet (SLAZ009 without 'a' or so) just begins with silicon revision D. No mentioning of earlier revisions or the experimental (pre-release) silicon. It's from 2006, so It may well be that I had an earlier silicon when I encountered the LPM problem. And the problem had been alrteady fixed before the errata sheet was created. > To summarize, in the absence of CPU errata, we have no evidence that > the MSP430 architecture allows code following an instruction that > enters LPM to be executed before entering LPM, or before the > instructions in an interrupt handler entered from LPM, or at any other > point before the CPU resumes normal execution. Any other behavior may > be considered a silicon bug. I agree completely. However: > There are several CPU errata, possibly related to partial execution, > that are avoided by adding a NOP including CPU18, CPU19, and CPU27, > but the problematic contexts are pretty unusual. The compiler should > implement the workaround without user code needing to insert NOPs. This would be a fix for almost everything. However, it's not so unusual to have a funciton call (without parameters) right after an LPM enter instruction. Which will trigger CPU18. The other ones are less usual, I agree. However, people expecting the compiler to 'just work' would be baffled if it won't because of one of the CPU errata. I'm pretty sure (and have proof in some cases) that many MSP coders don't even know about the errata sheet. Some just read the device datasheet and then ask how to program the listed modules (not knowing the users guide) and some only read the users guide and then ask about specificy which are clearly written in the datasheet. It' s a typical case of 'own fault', but a common one. Much too common. In my book about MSP (which currently only has two chapters) I dedicated a whole chapter to the MSP documentation and how and where to find things. This thread will surely have some influence on the next chapter about the CPU. :) (If I ever find the time to write it) > One of my TI contacts is preparing a list of the problems that the > compiler will need to work around, and I may be able to address them > in some upcoming peephole optimization work. That will surely be a great help. I'd like to have a list of all errata with an info to which devices they apply rather than to have many lists of which errata belong to a particular device. You do a great work for mspgcc. I'm really sorry that I cannot use your compiler right now. But at the current state (with still many unresolved issues and a quick update cycle) I cannot convince anyone to using it in production environment. The existing code has been built and tested on mspgcc 3.2.3 and I have to stay with it for some more time. Maybe on our upcoming 5x family-based devices, I may be able to switch, as I have to rewrite much of my library code anyway. And it's still some months before development wills start. JMGross ------------------------------------------------------------------------------ Systems Optimization Self Assessment Improve efficiency and utilization of IT resources. Drive out cost and improve service delivery. Take 5 minutes to use this Systems Optimization Self Assessment. http://www.accelacomm.com/jaw/sdnl/114/51450054/ _______________________________________________ Mspgcc-users mailing list Mspgcc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mspgcc-users
