4 ms·

Very often hardware bugs can be worked around by well-placed NOP. Last time I did that was on MSP430, where it seems that some integrated peripherals set compl

by dfox 10y ago

Very often hardware bugs can be worked around by well-placed NOP. Last time I did that was on MSP430, where it seems that some integrated peripherals set completion interrupt flag one cycle before the operation really completes. (I'm not sure whether it really is bug, I didn't find this documented anywhere, but for TI's example this does not matter and produces marginally better performance)

throwanem 10y ago
Which MSPs, if I may? I use some of their 2xxx hobbyist line (since I'm a hobbyist), and this sounds like the kind of PITA that I'm not nearly enough of an embedded dev to avoid tearing my hair out over.
- jlubawy 10y ago
  The MSP430x5xx and MSP430x6xx families have this problem. From the user-guide [1]: > Include at least one instruction between the clear of an interrupt enable or interrupt flag and the EINT instruction. For example: Insert a NOP instruction in front of the EINT instruction. > Include at least one instruction between DINT and the start of an code sequence that requires protection from interrupts. For example: Insert a NOP instruction after the DINT Luckily if you use the MSP compiler's intrinsic functions to enable/disable interrupts it takes care of this for you. [1] http://www.ti.com/lit/pdf/slau208 http://www.ti.com/lit/pdf/slau208
  - dfox 10y ago
    What I described happened on G2553 with USCI_A in SPI mode. Given the fact that various code samples on the net do not handle this behavior it seems that it is either happening only for some configurations or only on some versions of the HW. But: when you see even bytes on SPI dropped or replaced with previous ones, add NOP.
kevin_thibedeau 10y ago
This is a common flaw in many micros. It stems from poor discipline in transferring registers across clock domains.
userbinator 10y ago
Very often hardware bugs can be worked around by well-placed NOP. True of certain x86 bugs too: https://blogs.msdn.microsoft.com/oldnewthing/20110112-00/?p=11773 https://blogs.msdn.microsoft.com/oldnewthing/20110112-00/?p=...
deleted 10y ago
[deleted]

by dfox 10y ago

throwanem 10y ago

Which MSPs, if I may? I use some of their 2xxx hobbyist line (since I'm a hobbyist), and this sounds like the kind of PITA that I'm not nearly enough of an embedded dev to avoid tearing my hair out over.

jlubawy 10y ago
The MSP430x5xx and MSP430x6xx families have this problem. From the user-guide [1]: > Include at least one instruction between the clear of an interrupt enable or interrupt flag and the EINT instruction. For example: Insert a NOP instruction in front of the EINT instruction. > Include at least one instruction between DINT and the start of an code sequence that requires protection from interrupts. For example: Insert a NOP instruction after the DINT Luckily if you use the MSP compiler's intrinsic functions to enable/disable interrupts it takes care of this for you. [1] http://www.ti.com/lit/pdf/slau208 http://www.ti.com/lit/pdf/slau208
- dfox 10y ago
  What I described happened on G2553 with USCI_A in SPI mode. Given the fact that various code samples on the net do not handle this behavior it seems that it is either happening only for some configurations or only on some versions of the HW. But: when you see even bytes on SPI dropped or replaced with previous ones, add NOP.

kevin_thibedeau 10y ago

This is a common flaw in many micros. It stems from poor discipline in transferring registers across clock domains.

userbinator 10y ago

Very often hardware bugs can be worked around by well-placed NOP. True of certain x86 bugs too: https://blogs.msdn.microsoft.com/oldnewthing/20110112-00/?p=11773 https://blogs.msdn.microsoft.com/oldnewthing/20110112-00/?p=...

deleted 10y ago

[deleted]