• State Resolved
  • Locked Locked
  • Replies 10 replies
  • Answers 1 answer
  • Subscribers 80 subscribers
  • Views 2945 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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.

How to see what code was running when a reset occurs?

TI Lady
Genius 4025 points
Other Parts Discussed in Thread: MSP430F5418, MSP430F5418A

Is there a particular technique or tool we should use to see what code was running when a reset occurs on the MSP430? At the moment, it appears SYS8 from the F543x/F541x errata document is manifesting with our firmware. (The SYS8 erratum is related to interrupts occurring within 5ns of an MCLK rising edge.)

There doesn't appear to be a way to use the MSP-FET430UIF with Code Composer v4 to "trap" the instruction stream leading up to a reset.

Thanks,

  • 0
    TI__Genius 12770 points

    Amy,

    For MSP430x5xx and MSP430x6xx device the Embedded Emulation Module (EEM) can be used to implement trace to setup hardware breakpoints and to detect complex scenarios.

    See page 939 of the User's Guide for more information.

    MSP430x5xx/6xx User's Guide: http://www.ti.com/lit/ug/slau208j/slau208j.pdf#page=939

    Also you can use the SYSRSTIV register to read the source of a reset.

    See page 30, 35, 40 and 63 for more information on this register.

    MSP430x5xx/6xx User's Guide: http://www.ti.com/lit/ug/slau208j/slau208j.pdf#page=30

    Let me know if you have any other questions on this topic.

  • 0 in reply to Austin Miller
    Genius 4025 points

    Thanks Austin,

    At some future point, the customer will probably have to move to the 5418A. Can you tell me if the SYS8 erratum has been fixed in this chip revision?

    Thanks as always!

  • 0 in reply to Austin Miller
    Guru 227245 points

    Austin Miller said:
    After boot has complete, the value of this register is loaded into the Program Counter (PC).

    Well, sorry, no. Doing so would immediately cause a illegal instruction fetch exception and a reboot.
    Even adding this to the PC makes no sense if there is no (application!) code that makes use of it.

    The SYSRSTIV register is untouched unless the applicaiton code intentionally reads it.

    BTW, multiple resets are stacked in this register. However, only one occurrence per reset cause and the order the values are presented is the priority of the reset event, not the order in which they appeared.

    However, the users guide indeed tells "Upon completion of the boot code, the PC is loaded with the address contained at the SYSRSTIV reset location (0FFFEh)." Which is nonsense. 0xFFFE is the reset vector (RESET_VECTOR), which is loaded into PC after boot, but has nothing to do with the system reset interrupt vector register (SYSRSTIV).
    Page 35 is incorrect too, it must read "They are combined into three interrupt vector registers".

    It looks liek the one who wrot this had himself problems with the terminology regarding interrupt vectors and interrupt vector registers.

  • 0 in reply to Jens-Michael Gross
    TI__Genius 12770 points

    Amy,

    SYS8 does not apply to MSP430F5418A but does apply to the latest revision of MSP430F5418.

    Jens-Michael,

    Thank you for clarifying an incorrect post. I should have tested this first to verify what is documented in our User's Guide. But I trust your word because I am sure that you are making this correction from personal experience. Thank you again for your contributions to our online forum.

    Amy,

    Even though the contents of SYSRSTIV are not loaded into the program counter after boot, you should still be able to read this register in application code to determine the source of reset.

  • 0 in reply to Austin Miller
    Guru 227245 points

    Austin Miller said:
    Thank you for clarifying an incorrect post.

    Well, you cited the users guide, and if you cannot trust the uses guide anymore... (that's actually what brought me here into this forum: a bug in the users guide that contradicted my experiences).

    Austin Miller said:
    I am sure that you are making this correction from personal experience

    Definitely :) I used this feature first on the 5438 about 2 years ago.

    It's not the first time, people get confused with the interrupt vectors in the interrupt vector table (which hold the addresses of the serice functions, including the reset function that starts the applicaiton) and the interrupt vector registers (which provide prioritized information about different interrupt sources that are to be served with the same interrupt vector).
    I must admit that I never read this part of the 5x users guide (as I didn't expect it to contain anything different form the 1x users guide which didn't have a SYSRSTIV register)

    I added this issue to my long list of documentation comments. I think it's time to send Kathy the next batch :)

    Austin Miller said:
    Even though the contents of SYSRSTIV are not loaded into the program counter after boot, you should still be able to read this register in application code to determine the source of reset.

    Yes. that's the way it can be used.

    Keep in mind that this register is only cleared on a BOR. So if several (different) resets happened since last BOR (e.g. watchdog, key violation etc.), the register will report them all, one after the other. You should read it in a loop until it returns 0.

  • 0 in reply to Jens-Michael Gross
    Genius 4025 points

    Hi Austin,

    Does erratum PORT16 apply to the F5418? We've been having an issue with the MSP430 apparently resetting an FPGA connected to it. The issue would be explained by this erratum.

    Can you please confirm.   the erratum implies it should not affect pins common to F5438 and F5418.

    Thanks!

  • 0 in reply to TI Lady
    Genius 4025 points

    Hi there, Just checking in to see if you had a response yet on this one!

    Thanks!

  • 0 in reply to TI Lady
    Guru 227245 points

    The erratum applies to P9-11 only, and only if a power-up or RST reset (BOR) is followed by another RST reset within 500µs. You can ensure this by placing a proper RC combo on the RST line.

  • 0 in reply to Jens-Michael Gross
    TI__Genius 12770 points

    Amy,

    Jens-Michael is correct.

    This erratum only applies to the pins that do not exist on the 80 pin package and do exist on the 100 pin package.

    This includes Ports 9.x, 10.x, 11.x and P8.7.

  • 0 in reply to Austin Miller
    Guru 227245 points

    Austin Miller said:
    and P8.7.

    I don't think that P8.7 is affected. While this pin is not routed to the package pins, it is still internally there (Port 8 is fully implemented). I think you can set P8OUT.7 to high and low in output direction and see the change on P8IN.7.
    P9..11, however, are not implemented in the smaller packages (physically absent on the die) and therefore are affected.

**Attention** This is a public forum