• State Resolved
  • Locked Locked
  • Replies 7 replies
  • Answers 2 answers
  • Subscribers 79 subscribers
  • Views 1717 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

MSP430F248: MSP430F248 assembler: Enable Interrupts (EINT) followed by enter LPM3 followed by RET - NOP required?

Lo2
Expert 1935 points

Part Number: MSP430F248
Other Parts Discussed in Thread: MSP430F148,

Hello,

Is a NOP required between a EINT instruction and BIS.W   #0x00d0,SR (enter LPM3) and a RET?

This is the code:

  C390 861E           BIC.W   #1,Timer_B7_TBCCTL4
  D0B0 0010 8618      BIS.W   #0x0010,Timer_B7_TBCCTL4
  D232                EINT    
  D032 00D0           BIS.W   #0x00d0,SR
  4130                RET

EINT and BIS.W 0xD0,SR act both on register SR, there are a few posts on e2e that discuss the topic of a NOP after modifying LPM bits in the SR register (or EINT/DINT btw: https://e2e.ti.com/support/microcontrollers/msp430/f/166/p/53319/838507#pi316701filter=all&pi316701scroll=false)

The F248 has the bug CPU19 (unintentional register read after CPUOFF bit modification) and it also lists RET which is a MOV @SP+,PC (correct? please confirm), would that increment the SP register twice?

This code was generated form assembly using IAR workbench, so if there's a nop required I'd have to do it in assembly for every occurrence.

This project suffers from unexpected resets (data/timing dependant, not easily reproduced).

 

It is not the watchdog irq: the WDT vector 0xfff4 was redirected to 0xff00 which now contains 0x3fff (jmp  to self, deadloop) and the WDTNMI bit is 0 (==wdt triggers irq not reset).

 

After the unintentional reset I can catch the pc upon re-entry @4008 and look at the stack:

SP is @20F0

0x20F0: FFFF    5FE2    0000    0420    55AA    00DC    54EE    402C

4028:   12B0 5000           CALL    #0x5000 ; next pc 0x402c
55a6:   12B0 5F6C           CALL    #0x5f6c ; next pc 0x55aa
5f6c:   1204                PUSH    R4 ; on stack
5f6e:   1205                PUSH    R5 ; on stack

Interrupt, pushes PC, SR:
PC @ 5fe2
SR = FFFF ?

What happens if the upper bits in SR are set?

Best regards,

Lo

  • 0
    TI__Guru 56685 points
    Hello Lo2,

    From the looks of it it does sound like you are running into errata CPU19. Inserting NOPs after a CPUOFF instruction should solve your issue. When doing this in C code, the compiler would normally take care of this for you, but as you stated you were writing in assembly, you would have to add this in yourself.
  • 0 in reply to Jace H
    Expert 1935 points
    Hello Jace,

    thanks for the fast reply.

    The CPU19 bug would affect only the MSP430F248, the MSP430F148 errata does not show the issue.
    Can you confirm that the MSP430F148 does NOT have this bug?

    We have two different boards (same pcb, different uC), both have unexpected resets. The F248 board could be affected due to the CPU19 bug. If the F148 does not have the bug, I need to keep searching.

    Currently I'm trying to reproduce the CPU19 bug in a minimal asm project to check if my results on the stack match the results of the CPU19 bug.

    Best regards,
    Lo
  • 0 in reply to Lo2
    TI__Guru 56685 points
    Hello Lo2,

    MSP430F148 is not affected by CPU19 as indicated in its errata document. However, upon further investigation, this part is labeled as possibly affected, but has never been confirmed. Hence why it is not in the errata document. This is unusual as typically our parts are tested in simulation to make sure they are not affected by errata once an erratum is identified. I am unsure as to why the MSP430F148 was not done this way, but I would have to guess it has to do with how old the part is and practices that may have come about since its release. I can say that this errata has not been reported as present for this part.

    That being said, the only practical advice I can give is this. You could implement the CPU19 workaround on your project to see if it fixes the issue. If it does not, then other avenues of discovering the resets must be investigated. The three most common areas I would investigate are:
    1. Delayed service of Watchdog timer
    2. Flash access violations causing reset. Usually caused by rouge pointers or array out of bounds coding errors.
    3. Frequency vs Voltage violations.
  • 0 in reply to Jace H
    Expert 1935 points
    Hi Jace,

    The CPU19 bug is harder to hit than it looks from reading the errata. My first attempt was not successful. If I get that to work on the F248 I'll run the same code on the F148, just to make sure.

    If you have a comprehensive list of errors that cause a MSP reset, I'd be interested to gat a copy of it.

    I disabled the watchdog (wdt-> interrupt -> deadloop). It's a plain assembly project, but I'll double check my flash accesses. Frequency and voltage issues are probably no issue as it uses the internal oscillator in default mode and is battery (=lab power supply) driven.

    Best regards,
    Lo
  • 0 in reply to Lo2
    TI__Guru 56685 points
    Lo,

    the three issues above are the most common for resets. As far as hitting CPU19 is concerned, it is a very hard bug to reproduce. The internal notes on this one are extensive and were hard to reproduce. A change in IDE/Compiler/Assembler also masked and/or showed the problem as well.

    My only next step advice is if you are able, to add in GPIO toggles in different parts in the code to see where you are before it resets.
  • 0 in reply to Jace H
    Expert 1935 points

    Hi Jace,

    can you share more details on the CPU19 bug? (per PN or under NDA if required)

    If the CPU19 bug is hard to reproduce that would match my observations: insert some instructions at a non-related place in the code makes it disappear. But that could also be true for a totally different bug (sw or hw).

    I want to make sure that this is the CPU19 bug, insert the nops and be sure that I fixed the right issue. Inserting pin toggles at different places is hard, because depending on 'something' (what? depends what the cpu19 bug depends on...) the bug does not appear.

    I dumped SFRs and peripherals from 0x0-0x1ff on different runs and compared them with each other but I can't see anything suspicious. There are a few non-assigned locations which read garbage but for the defined peripherals the values are the same/correct or different due to their nature (TAR/TBR, ADC, ...).

    From a user perspective I'd say the range from 0x0 to 0x1ff + the cpu registers define the visible MSP430 state. The application spends quite some time entering/leaving exactly this state with some minor differences in RAM, but it always fails at the 36th loop, if it fails.

    More information about the dependencies of the CPU19 bug would be very helpful, also with regard to the F148 based board.

    Best regards,

    Lo

  • 0 in reply to Lo2
    TI__Guru 56685 points
    Lo,

    There is not much I can add about the CPU19 errata, especially when it comes to MSP430F148 as it has never been confirmed to be seen on that device. In either case, if you follow the workaround in the errata text to add the specific assembler flag, the assembler will add in the NOPs in the appropriate place to workaround CPU19. If you are still getting your resets after enabling the assembler flag, then your issue is not CPU19.

    The appropriate assembler flags per IDE are located in the errata text for CPU19.

**Attention** This is a public forum