DINT after EINT

Actually, it shouldn't be necessary to place a NOP behind the EINT. But it depends on the inner timing of the MSP.

The whole problem is cause by the fact that instructions are pipelined in the MSP code.

EINT requires two MCLK cycles. (I know, the manual tell different - and for a reason).

If looked at isolated, it takes one clock cylce to load the EINT opcode from FLASH, and anotehr cycle to decode and execute it. Two cycles.

BUT

while EINT is executed, the next instruction is fetched from FLASH. So two instructions always overlap by one cycle.
(this is why instructions affecting the PC are so slow - the execution part is extended by one cycle after the new value of PC is known)

The problem with EINT/DINT is that when EINT is executed, DINT is already fetched and will be executed before any ISR may kick in. THEN the execution of the ISR will be scheduled, while GIE is already cleared.

If you set a breakpoint on DINT, you'll see it hit and THEN the ISR is done as if DINT wasn't executed at all. The debugger simply cannot handle this overlapping, since the breakpoint happends at the moment DINT is fetched.

Similar things happen if you make DINT and then do an atomic operation. The first instruction of the atomic operation is already fetched before DINT has cleared GIE and it is well possible that an interrupt has just kicked in, interrupting the atomic operation and causing havoc.
Same thihg happens when entering LPM and placing a breakpoint behind the LPM instuction. This instruction is already fetched before MCLK is disabled, so a breakpoint at this point will be triggered BEFORE the device has entered LPM. And I think this next instruction will be executed before the ISR is called.

i hope this explains the unpredictable behavior you're experiencing.

Peter,

please also be aware of the bug "CPU39"  in the errata for the F5437:

http://www.ti.com/litv/pdf/slaz046f

This doesn't help in your special case, but it would explain, why you need a NOP after the DINT statement, at least in single step mode.

Regards,

Torsten

We actually made a small program to demonstrate the issue. To my oppinion it is nearly worth to mention as an errata or a strong recommendation in the users guide.

In our application the problem showed up in a critical situation at one of our end customers. It took a very long time to figure out this issues as it was hiding in a port to freeRTOS where to macro's together made the EINT DINT sequence.

Best regards

Peter Johansen

#include <msp430x54x.h>

// A red/green LED is attached to port 8

#pragma CODE_SECTION(SYSNMI_ISR,".text:_isr");
#pragma vector=SYSNMI_VECTOR
__interrupt void SYSNMI_ISR(void)
{
    P8OUT |= BIT1;
    for(;;);
}

#pragma CODE_SECTION(UNMI_ISR,".text:_isr");
#pragma vector=UNMI_VECTOR
__interrupt void UNMI_ISR(void)
{
    P8OUT |= BIT1;
    for(;;);
}
// Timer A0 interrupt service routine
#pragma CODE_SECTION(Timer_A0,".text:_isr");
#pragma vector=TIMER0_A0_VECTOR
__interrupt void Timer_A0 (void)
{
    P8OUT ^= BIT2;
}

void main()
{
    WDTCTL = WDTPW + WDTHOLD;
    SFRIE1 |= VMAIE + ACCVIE;
   
    P8OUT &= ~BIT2;
    P8OUT &= ~BIT1;
    P8DIR |= BIT1;
    P8DIR |= BIT2;
   
    TA0CTL = TASSEL_2+ID_2+MC_0;       
    TA0CCR0 = 2;            //Load timer register
   
    TA0CTL |= MC__UP;       
    TA0CCTL0 |= CCIE;        //Enable sample timer interrupt   
   
   
    for(;;)
    {
        __enable_interrupt();__no_operation();
        __disable_interrupt();
    }
}

We also found this issue - after about six hours of debugging, which we could not afford.

This is definitely a bug in the system. We had a function that called DINT at the start and EINT at the end. We called the function twice in a row. The compiler inlined the function, so that DINT was called immediately after EINT. The system would either reboot immediately, or be rebooted by the watchdog.

Future compilers should insert a NOP after EINT. This is simply broken and unacceptable. TI, are you listening???

Hi Chris,

in the msp430 family user's guide you can find following paragraphs for the EINT and DINT instructions:

NOTE: Disable Interrupt

If any code sequence needs to be protected from interruption, the DINT
should be executed at least one instruction before the beginning of the
uninterruptible sequence, or should be followed by a NOP instruction.

NOTE: Enable Interrupt

The instruction following the enable interrupt instruction (EINT) is always
executed, even if an interrupt service request is pending when the
interrupts are enable.

You have to ensure yourself that an extra NOP command is inserted in the right place if you have possible EINT DINT sequences.

Chris Phoenix said:

This is definitely a bug in the system.

It's not a bug, it's a feature ;-)

Best regards,
Christian

It's nice to see that it is now included in the user's guide.

I agree, that it is very time consuming to find this 'bug'.

If possible some kind of warning in the compiler would be wellcome. It might be very seldom that anyone could use the 'feature' without the NOP.

Best regards

Peter Johansen

Yes, well, a similar feature on DINT causes the _disable_interrupts() intrinsic to put a NOP after the DINT. The right fix is to make _enable_interrupts() add the NOP just like _disable_interrupts. A programmer who really cares about the single lost cycle, and who knows the implications, can use _op_code(EINT) to avoid the NOP. Just like they can on DINT, if they have a non-atomic instruction handy.

Given how easily an EINT at the end of one function can be followed by a DINT at the beginning of another, and given that this depends on subtle details of compiler optimization, and given the arcane interaction that causes DINT to blow up the system when executed at the start of an interrupt handler, I don't think it's reasonable to expect programmers to realize the implications of that paragraph.

In fact, I'd give three-to-one odds that, at the time the TI programmers decided to put NOP after DINT but didn't put one after EINT, they _didn't realize_ that this interaction existed. If they had, they should have put the NOP after EINT as well. And if they did not realize it, then it is a design flaw with a workaround, not a feature.

The MSP430 family has way too many quirks and unimplemented workarounds and errata (including the FLL which works most of the time, but sometimes varies enough to cause serial errors - that was good for quite a few wasted hours). It's nice that it's low-power, but if we hadn't inherited a lock-in to it, I'd be pushing for us to evaluate other families.

This bug is fixed in MSPCGT v4.1.3 and noted as silicon bug CPU42. Search for SDSCM00045449 in TI's ClearQuest database (link):

Release Notes:

Silicon bug CPU42 appears when an enable interrupt (EINT) instruction is followed immediately by a disable interrupt (DINT) instruction.  The solution is to place a NOP in between the two instructions when the --silicon_errata=CPU42 option is specified.  The option is disabled by default.  If the --silicon_errata option is enabled in the assembler and an EINT followed immediately by a DINT is encountered, the assembler will issue a warning that the assembly instruction sequence may expose a silicon bug.

Best regards,
Christian

The "readonly" login does not work for me in the bug database (though I think it used to last night). So your link doesn't work. Even editing the URL to remove "readonly" doesn't work. "ClearQuest login of user: This login is forbidden: CRMMD1881E Invalid Credentials: Either the login name or the password is incorrect. "

I only downloaded CCSV5 a couple months ago.... I see that I have Compiler Tools version 4.1.1. So that means I'm also exposed to "Loop nest over two-dimensional array compiles wrong if inner loop has early exit". Ugh.

I found 6153.DefectHistory.txt, which says:

Silicon bug CPU42 appears when an enable interrupt (EINT) instruction is
followed immediately by a disable interrupt (DINT) instruction.  The solution
is to place a NOP in between the two instructions when the
--silicon_errata=CPU42 option is specified.  The option is disabled by
default.  If the --silicon_errata option is enabled in the assembler and an
EINT followed immediately by a DINT is encountered, the assembler will issue
a warning that the assembly instruction sequence may expose a silicon bug.

If I read this correctly, the fix is only enabled if the --silicon_errata=CPU42 option is enabled - which, by default, it is not, even in 4.1.3. So each user will have to manually enable this? So we will each have to do the research and realize the problem exists?

I know you guys have put a lot of work into the chips and the IDE... but they're still pretty far from "just working." The number of errata already found, and the fact that data-corruption and system-crash bugs are still being found at a high rate, implies that there are a lot more waiting to surprise us.

Chris

I just noticed the original poster posted about this bug in 2010. Either TI is not reading these forums, or they are taking FAR too long to fix serious problems.

Chris Phoenix said:

The "readonly" login does not work for me in the bug database (though I think it used to last night). So your link doesn't work. Even editing the URL to remove "readonly" doesn't work. "ClearQuest login of user: This login is forbidden: CRMMD1881E Invalid Credentials: Either the login name or the password is incorrect. "

Sorry Chris, it is my fault with simple copy & paste. I just stumbled across a "feature" of another prevalent software vendor. ;-) 

This one should work (SDOWP).

Chris Phoenix said:

The number of errata already found, and the fact that data-corruption and system-crash bugs are still being found at a high rate, implies that there are a lot more waiting to surprise us.

I can understand your displeasure very much. I even spent long nights in front of the debugger and was already about to doubt about me. It is very annoying when you stumble across an error by the compiler or chip (The FLL has also been annoyed me earlier), which you did not expect. But it would be too simple to say that all system errors result from faults caused by chips or bad compiler. Poor, vulnerable or fragile system design is often homemade by us developers. The final result is important at the end. If you're forced to work with a faulty tool, you have to look for an alternative solution or workaround for that problem. Ultimately, we are engineers. Sometimes it's just creativity. But then it is very important to document your choosen workaround for that tools error in your code in detail. Otherwise you wonder about this lively solution years later and other developers can understand your code. --- By the way, i've also often wished that some major errors are cleaned up even faster. But, instead I have the impression there's a focus on implementing new features, which many times leads to long-beloved things suddenly stop working and you have to wait for a fix --- Here in this forum you can describe your problem or search for a known solution. Maybe you'll get an answer from somebody. But this forum is primarily E2E with dedicated engineers. It's moderated by TI staff only who mediate between us users on the one side and TI's developer teams on the other side. They pass known problems to them. But if you have a paid tool, you have the ability to contact TI's support directly.

Christian

Chris Phoenix said:

Yes, well, a similar feature on DINT causes the _disable_interrupts() intrinsic to put a NOP after the DINT.

The NOP after DINT is required due to the pipelining structure of the MSP CPU core.
When an instruction doesn't require a memory access to write its result (and since DINT writes to SR - it is nothing but a BIC #GIE,SR instruction - teh result write doesn't require a memory write) the next isntruction is fetched during its execution.

Now in this case, the instruction following the DINT is already fetched at the moment when GIE is cleared. Now at this point, an interrupt may already have been granted (after fetching the DINT instruction but before executing it), and sicne the following isntruciton was already fetched, it will be exeuted before the already granted interrupt is performed.

Since people are usually unaware of how things really work, this fact is mostly unnoticed. And the DINT() macro puts a NOP behind the DINT to ensure that the next program isntruction won't be interrupted (any possibly pending interrupt happens between the NOP and the next program isntruction then)

THsi is no bug and well documented (and even obvious if you think about it).
The good old Sparc with its pipeline did have a so-called 'delay slot'. The instruction after a call or branch was always executed before the call or branch took place. Due to the pipelining too. In too many cases, this delay slot was filled with a NOP too. The only difference was that every code knew about it. If not, even the simplest program failed.
On the MSP, the CPu core takes care of these things by adding an implicit NOP (at the cost of an additional clock cycle) on these instructions, so the coder doesn't have to take care of it. However, for the GIE bit, there was no such workaround.

The bug with an EINT following a DINT is something completely different and rather unexpected, even by studying the CPU architecture (as far as available).

Chris Phoenix said:

The MSP430 family has way too many quirks and unimplemented workarounds and errata

Can anybody tell me where CPU42 is documented -- I mean, which errata sheet, for which processor?   Thanks in advance.

I have done some testing on a MSP430F5529 and found that either one or two instructions following the EINT are executed, depending on the instructions, if the EINT executes while interrupts are pending but masked by GIE=0.

That seems to be cause for concern over how soon one should execute a DINT after an EINT, so I would like to see the erratum.  I just can't find it.

Jeff

Jens-Michael and Christian, I know about the SPARC delay slot, and I agree that NOP after DINT is the same kind of feature. I was in college around the time SPARC came out; I took a CPU architecture class from John Hennessy. So I'm not complaining about NOP after DINT. (From what I've read online, some toolchains did not support it for a long time - that's a whole different story.) I mentioned the NOP after DINT simply because the required fix is very similar for NOP-after-DINT and no-DINT-after-EINT. I'd have thought it would have been simple to understand the problem once it was reported, and put in the fix. Given that TI engineers are reading this site, I don't understand why it took two years for a fix for the EINT-DINT problem to get into the toolchain. And by the way, CPU42 is not in the MSP430F5438A errata sheet (slaz290b.pdf) yet.

I don't mind working around quirks that I know about. As you say, that's what engineers are for. I don't mind well-documented errata, no matter how voluminous. But the errata list for this chip feels like there are likely to be more problems that are not yet found. Yes, as an engineer, it is my job to make the chip work - and, bigger picture, to make a reliable product. But it is not my job to reverse-engineer the chip, or to find bugs in it; we didn't budget for that. And at this point, I don't believe a really reliable product can be made with this chip - which stresses me out, because that's still my job.

IMO the FLL should have a warning in the datasheet that its timing varies a lot (enough to cause serial port bit errors) if the power supply varies by more than (I think we measured) 50 mV. I've seen datasheets for other CPUs, from other companies, get very specific about decoupling cap size and placement and power cleanliness; this datasheet has one cryptic sentence about cap size, and nothing about cap placement or allowable power noise. (I didn't design our power supply, schematic, or board layout; but when I found the problem, there was so little documentation that it was very hard to convince the hardware engineer that his design wasn't suitable for this chip. We eventually just added an external resonator.)

I suppose I shouldn't be venting on an E2E board. Thanks for listening.

Chris, IMO you're not been misplaced here. It's the right place to discuss this problem in general and to investigate its cause. Here is a lot of experience on the MSP architecture such as Jens-Michael and the other gurus and masterminds for example. But your question applies to both MSP and its code generation tools. So you can even try to ask for support in TI's specific C/C++ compiler forum. Those guys are really fit with compiler issues and provide very good support, too. Maybe they can give you some information about schedules, as they have good contact to the compiler team or have very good insight into the inner workings. Perhaps that guys are even the developers themselves, but I do not know exactly.

Sorry, I meant the DCO's timing varies, not the FLL. If the FLL/DCO combination is suitable for some environments and not others, then the datasheet should explain what environments it's not suitable for. The fact that the DCO drifts is documented, but not under what conditions. There's no way, currently, to know whether a board design is adequate other than guess-and-hope and then test it exhaustively.

I agree that some of the interactions you describe (FLL won't work if its source is switched off in LPM) are not errors. But they're worth documenting somewhere, and if they didn't get into the original datasheet then they might as well be put in the errata, since it's more of a living document.

I'm using the 5438A chip. The DINT-after-EINT bug "CPU42" is not in its errata sheet that I downloaded yesterday. Two years after it was noticed, and at least some time after it was fixed. At this point, I'm kind of sour on the whole family. Yes, older chips _might_ have _most_ of their errata documented... but I bet CPU42 applies to a lot of older chips.

At this point, it's probably moot, because my boss agrees with me that we need to look for another chip family for future designs.

Chris

Chris Phoenix said:

The fact that the DCO drifts is documented, but not under what conditions.

Well, I agree that the maximum drift would be interesting.

IMHO, it's not a good approach to ask for exact values up to 10 digits and then desing the applicaiton right to that value. But I'm rather old-school here: An engineers calculates to three digits precision, adds 10% safety margin and then triples the value, just to be sure.

Following this rule, a drift of 1.9% morphs into 6.3%/V. And when 0.5% is the allowed maximum, then 79mV is the maximum tolerable VCC change.
Taking into account the 'swing' introduced by FLL and temperature changes, even less.
And if this won't work out, then use a crystal. Most other processors won't work without a crystal (or at least resonator) at all.

Chris Phoenix said:

agree that some of the interactions you describe (FLL won't work if its source is switched off in LPM) are not errors. But they're worth documenting somewhere, and if they didn't get into the original datasheet then they might as well be put in the errata, since it's more of a living document.

Chris Phoenix said:

but I bet CPU42 applies to a lot of older chips.

I'll go and try some code on my 5438, whether I can confirm this problem at all.

But even if, now that it is known, it is easy to fix and all this discussion was lots of hot air for nothing. Adn I really doubt that on other CPUs all bugs have been found. There's always a chance that an undetected one bite you in the nose.

Chris Phoenix said:

At this point, it's probably moot, because my boss agrees with me that we need to look for another chip family for future designs.

If you're suggesting that CPU42 may not be a real bug, then you apparently haven't read the bug database, which was linked to in this thread. And I'm not the only person who has found and reported this bug.

I don't want to get into a pissing contest with you. Obviously you're a valued contributor here, and you have lots of firmware engineering experience. So do I. I understand that you don't want me to be right. I'm not quite sure why. Does it somehow make you wrong if I am right about CPU42? Are you emotionally invested in the trustworthiness of this chip family?

'Nuff said. I've got work to do.

Chris Phoenix said:

If you're suggesting that CPU42 may not be a real bug, then you apparently haven't read the bug database, which was linked to in this thread. And I'm not the only person who has found and reported this bug.

I was jus tpointing out that the bug, whil ebeing in the bug database, has not made it into a single device errata sheet. While many others have been added since. So this must have a reason.

Besides, the bug database is no official resource for developers. The official resources are the datasheets, the errata sheets and the user sguide. No trace of CPU42 there. Perhaps it was just forgotten, that's of course always a (rather faint) possibility.

Chris Phoenix said:

I don't want to get into a pissing contest with you.

Chris Phoenix said:

I understand that you don't want me to be right. I'm not quite sure why.

Often enough I read threads about suspected silicon errata. The usual tenor is "I cannot see anythign wrong with my code, so it must be a chip bug". 90% of them are caused by soem detail that could have been seen after a closer study of the datasheet or the users guide (it these documents were consulted at all).
9% are solved after looking into the errata sheet. The remaining 1% are the interesting cases that may or may not be real silicon errors. (the rest are rather "silly-con" errors)

So my statement here is that there are too many open questions to give a definitive result on this topic and blame someone. This may change when more information is available.

However, there is no reason to believe that TI will intentionally keep CPU42 a secret or is generally lazy in disclosing silicon bugs. Or that the MSPs are not reliable or trustworthy. (at least not less than others)

To our company, this "feature" has costed us a fortune and loss of a major customer. As we cannot roll back history, we need to make sure that we will not have further problems in any new code.

So the simple question is, how can we let the complier check for this 'feature' now that the CPU42 seems not to be available to include ?

PS. In general we find the TI products very well documentet. Unfortunately we are amomg the '5%' raising serius questions having a major impact on our business. This question is one of those.

Peter Johansen said:

To our company, this "feature" has costed us a fortune and loss of a major customer.

Years of experience have told me that there's nothing that will 'just work'. From a box of matches to a car, there are always bugs. Undiscovered or just undocumented.

AFAIK, there's only one MSP certified for medical devices. I guess (and this is a guess only) that this one will be tested so thoroughly that there are no further unknown bugs to expect. For everything else (not limited to the MSPs, but rather including everything from compiler and OS to the PCB and its components), there's always a not too small chance of a bug that will cost you an eternity to figure out and fix.

Well, that's why people pay for development instead of doing it themselves. :)

Peter Johansen said:

So the simple question is, how can we let the complier check for this 'feature' now that the CPU42 seems not to be available to include ?

BTW, if you remove the 'verified answer' from my previous post, this increases the chance that the thread will be visited by an 'official'. I don't mind losing the 10 points :)
As I'm told, the 'verified answer' tags are used to determine whether a thread still requires further attention or not.

Maybe we should just clean up and end this threat and start a new one focusing on the options ahead ?

First let me apologize on behalf of the MSP team that this topic has caused so much headache for those on the thread as well as some that perhaps are just monitoring. The comments here regarding the pipeline architecture of the CPU are well placed and are at the core of the behavior that has been described. Just prior to this thread becoming active again, we realized that the information and wording in the UG's was not sufficiently adequate or clear for our users. Updates have been in the works over the holidays and are being released today to hit TI.com. Changes can be identified at the back in the “Revision History” section- relevant to this thread, the following clarification is now added:

The comments regarding compiler are spot on. In addition to the UGs, new compiler updates are being finalized and will be released the week of Jan 21st. The updated code gen tools will automatically insert a NOP after EINT as has already been the case for DINT for some time. This is true for C coding; for assembly the tools will return a warning that this specific sequence was detected such that action can be taken by the developer.

Regarding the "CPU42" topic, this is the internal naming by which we drove the compiler changes related to the pipelined behavior for back to back EINT-DINT execution. As with a few other similar toolchain/CPU corner case behaviors, TI has chosen to more clearly describe the behavior in the UGs as well as avoid the corner case directly - and automatically - in the compiler. The goal in this approach is to avoid publishing cryptic and potentially confusing documentation while making the handling as automatic and transparent as possible for the developer.

Again, my sincere apologies for the pain and suffering induced by the lack of clarity here. It is definitely not the MSP team's intent to do so and we will continue to work to improve and hopefully avoid such instances moving forward. Our constant goal is to have best in class devices, tools and documentation for our users. Thanks to all those E2E members that have shared valuable information here with others to help work through the questions.

Thanks for your continued use and support of TI's MSP products, Zack

MSP Applications & Embedded SW Team

Zack, thank you for posting this.
It puts an end on this discussion and picks up any loose ends.

I want to suggest to add to the cited note (as it refers to EINT and DINT), that for the same reason an interrupt that occurs during a DINT instruction may still be executed after the instruction that follows the DINT. (even though the time window for this is very short)

This is already handled by the compiler in the DINT macro by adding a NOP, but not so in assembly.

It's also a typical (and related) error that people place a breakpoint on the isntruction following an LPM entry. The typical comment '// for debugger' in the demo codes is often enough misinterpreted as being the point to place the breakpoint on. However, a breakpoint there will be triggered on instruction fetch and therefore before LPM is entered.
I don't know whether the instruction is executed when MCLK reappears (before the ISR is executed) or discarded, but it is definitely fetched before LPM entry and triggers the breakpoint. Many people have been fooled by this, thinking that their ISR is never called or the LPM entry is not working.

Zack, thank you for your update on this topic.

Jens-Michael Gross said:

I want to suggest to add to the cited note (as it refers to EINT and DINT), that for the same reason an interrupt that occurs during a DINT instruction may still be executed after the instruction that follows the DINT. (even though the time window for this is very short)

I have to agree with JMG, some more detailed information would be better. IMO 'pipelined CPU architecture' should be clarified, too. I am working for nearly a decade with MSP430-based projects now. I know out of experience the MSP430's can read the next instruction while it is still executing the final operation of the previous one. But it is the first time I read 'pipeline' in an UG about the MSP430 family and it is the only place where it is even mentioned. The different TI docs never explicitely mentioned this and officially it is even denied (link).

Jens-Michael Gross said:

It's also a typical (and related) error [...]

Many people have been fooled by this [...]

I want to suggest some further notes to the 'CPU Introduction' or 'Instruction Set' chapters of the UG's about this 'pipelined CPU architecture', instruction prefetch, the underlying pipeline mechanism or whatever the MSP430's are using and it is named by TI. In the hitherto existing UG's it is only statet indirectly based on the instruction cycles. That would make it easier for newbies to the MSP430 architecture and avoid many mistakes and misunderstandings using the debugger with ISR's and LPM's.

Christian Steffen said:

is the first time I read 'pipeline' in an UG about the MSP430 family and it is the only place where it is even mentioned. The different TI docs never explicitely mentioned this and officially it is even denied

Well, nobody 'official' denied it in this thread.
However, some RISC purist claim that 'pipelining' means a strict n-step pipeline. first step, fetch, 2nd step decode, third step execute. (whiel on 2nd step, the next instruction is fetched etc.). This is of course only possible if code and data memory are separate (so instruction can be fetched shile data is read or written) and if every instruciton has same size and is read with one read access (very long isntruction word, always same size as memory width)
And it has bad side-effects, like the instruciton after a branch being always executed, whether the branch is taken or not. Same for calls (instruction after call or return is executed before call or return are performed).

The MSP uses instructions of variable length, has unified memory architecture (von Neumann) with combined code and data bus (allowing data stored in code memory and code executed from data ram) and also doesn' tneed two clock cycles for decoding an instruction and executing it.

However, th einstruciton prefetch that is done on some instructions is some sort of pipelining. (x86 processors also use this and even more, while not following the 'strict' pielining idea - and nobody denies that todays x86 processors use pipelining - and way more complex mechanisms like out-of-order execution)

Christian Steffen said:

In the hitherto existing UG's it is only statet indirectly based on the instruction cycles.