How to research and workaround CPU errata - quickly???

Chris Phoenix said:

How do other MSP430 engineers handle this?

Well, because you're explicitely asking...

I have some code (actually quite old) for writing to flash. Since a flash write takes some time and interrupts need to be disabled during a flash write operation, I shortly enable them between writes.
Because of this (and the other) thread, I checked my code and found that I was explicitely placing two NOPs between EINT and DINT, with the comment 'give some time to any pending ISRs'.
I don't know whether the code would have crashed without these NOPs. I just was aware that there might be more than one ISR pending and added the two NOPs. Without knowing of any possible silicon bug.
It's not the only situation where I circumvented a bug without knowing about it at all, just by being 'aware' of the circumstances.
Many problems go away or do not even pop up if you visualize what happens rather than what you want to happen.
However, this requires some base knowledge. If one doesn't understand how things work, he cannot see where reality and his imagination drift apart. (like pushing 10 bytes in a row into TXBUF and wondering why only the first and the last arrive - which obviously must happen if MCLK is much faster than the baudrate).

Maybe it's just because I'm curious above average. I want to understand how things work rather than just picking keywords form a sample code. It takes a bit more time, but it pays at the end.

Ask yourself one question: how come that the errata sheet contains entries at all? Apparently someone must have indentified the problem. If he could, why can't you? I doubt that most of the problems were identified by looking at top-secret internal TI documents like silicon blueprints.
Sure, it's convenient to have an environment that simple works. But world is less than ideal. And being aware of this is one of the differences between a software engineer and a software designer.

In our case, it was definitely triggered by powersupply - we could put a scope on the power line, and a square wave output by the chip, and trigger on extra-short pulses on the square wave, and the power line spikes would always be there, a microsecond or two before.

If I understand UCS10, it can only happen around the time of a FLL-controlled DCO tap change, which can only happen when REFCLK transitions, which takes well over 10 us. So I don't think It's possible that the power supply spikes were activating UCS10.

I think I also remember that the frequency shifts also happened when using the DCO with FLL turned off. I'm 90% sure of that.

Congratulations on finding those, BTW.

On CPU42, I was writing straight C code, with optimization level 4, speed-vs-size 0, and Configuration Debug (if that makes any difference), in toolchain 4.1.1, for MSP430F5438A. By code was essentially this:

void BadFun(struct *param)

{

  _disable_interrupts();

 param->field = volatile_variable;

_enable_interrupts();

}

void CrashIt(void)

{

BadFun(var1);

BadFun(var2);

}

When I looked in the disassembly view, it showed that the calls to BadFun had been inlined, and EINT was immediately followed by DINT.

The crashes were interesting; depending on exactly what code I added to BadFun, sometimes the CPU would reboot immediately, and sometimes it would hang until the watchdog timer rebooted it. During the hang, the timer-tick interrupt would not be serviced (or else the I/O pins I was twiddling in the interrupt handler were disabled somehow).

Interestingly, I could put one I/O pin twiddle in the middle of BadFun (e.g. P5OUT |= 1), but not two; that would make it stop crashing. I didn't check the disassembled code, so this is probably just optimizer magic.

Chris

Maybe UCS10 actually caused your power-supply spikes.  The DCO accelerating by 10% "instantly" could easily have that effect on the power supply.  The "short" output pulse would come soon afterward as evidence that UCS10 happened.

On CPU42, your function BadFun() isn't normal because it "blindly" enables interrupts.  Typically it would look like this instead:

void BadFun(struct *param)

{

  save_interrupt_status();  //  MOV.W  SR, [ ]

  _disable_interrupts();  // DINT

  param->field = volatile_variable;

  restore_interrupt_status();  // MOV.W [ ], SR

}

which would have prevented CPU42.

Jeff

No, the spikes happened in the power supply without the CPU hooked up. Just bad design. The CPU did inject additional noise into the line, but the spikes were a different shape - very distinctive.

But I'm realizing that I didn't verify that every spike caused the timing change. It's possible that it happened only when a spike coincided with REFCLK. So it could still be UCS10 after all... if my memory is wrong about the timing change happening even when the FLL was off. But the more I think about it, the more I remember that we looked at the UCS10 fix, tried it, and found it didn't solve the problem for us. Anyway, it's moot for us, because we were able to put an external resonator on the board.

I can see why save/restore would prevent CPU42. In my code, I'm not calling BadFun() from anything that could have already disabled interrupts. Your version is more paranoid, and thus better. :-) But I wouldn't have thought that everyone would use it automatically. Am I missing some way that interrupts can be disabled without my code explicitly doing it?

BTW, thanks for actually answering my question about where to find errata.

Chris Phoenix said:

Am I missing some way that interrupts can be disabled without my code explicitly doing it?

Interrupts are also disabled during interrupt acknowledge (when preparing to call your ISR), but you already knew that.

Most of the commercial and professional code I see uses the save-disable-restore approach.  Just makes the function a bit more agile, ready for use by any caller.  Not really sure about code in the hobbyist community.  (Actually, off topic, I think most people over-use interrupt masking.  Good design often eliminates the need.)

Anyway I think I'm going to do some CPU42 experiments too.  I can't understand why it does NOT appear in the errata sheet.

Jeff

Jeff Tenney said:

Most of the commercial and professional code I see uses the save-disable-restore approach. 

Especially if you use it inside a funciton that is called from an unknown caller, it is mandatory to save the current state before disabling interrupts. (and code shouldn't enable interrupts at all if they are disabled,a sthis usually has a reason)

I once created a macro that increments and decrements a counter for "critical sections" and disables interrups, but only (and then always) enables them when the counter is decremented to 0 at the end of the macro. It allows for unlimited (well, 65535) nested critical sections.

Jeff Tenney said:

I think most people over-use interrupt masking.  Good desing often eliminates the need.

I completely agree. But when you use long global variables that are changed by an ISR and read by main, it is necessary to disable interrutps while readoing the variable. And there are some other situations where you cannot allow interrupts, like writing to flash.