• State
  • Locked Locked
  • Replies 2 replies
  • Subscribers 79 subscribers
  • Views 795 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.

Recovering from bad address programmed to reset vector

Nick Vallidis
Prodigy 60 points
Other Parts Discussed in Thread: MSP430F5528

Hi,

I am trying to figure out how to recover from a badly programmed reset vector.

I am using a MSP430F5528 and working on a replacement BSL. Using the Code Composer custom BSL example, I built a version for the 5528. I used the MSP430Flasher program to attempt to push this into the device's flash. Unfortunately, I didn't have the flag set to turn off protection for the BSL memory segments and the only thing that ended up being written to the device was the reset vector. Of course that reset vector address didn't match any reasonable location in the existing BSL so it looks like the micro goes into a weird state (reset loop because of watchdog maybe?).

Now, anytime I try to access this micro with Code Composer or MSP430Flasher, I get the dreaded "Device Unknown" error message.

Using a development kit and performing the same error as I did above, I've found that I can use the USB BSL in the micro to erase the reset vector and return the msp430 to a usable state. Unfortunately, the target board I'm working on doesn't have any connections to the USB pins on the msp430 (the BGA version...) so I cannot use this method to recover my target board.

Anyone have any ideas how I can recover this msp430/erase the reset vector? It really seems like this should be possible to do through JTAG (actually Spy-Bi-Wire in my case), but the "Device Unknown" error prevents me from doing anything through Code Composer or MSP430Flasher.

  • 0
    Guru 227245 points

    The BSL is (normally) not called through the reset vector. It is called by internal startup precedure before the reset vector is called. The entry points are fixed and described in the appnote about the BSL programming.

    However, if you wrote the reset vector without the app it points to (because the BSL area was locked), the (still unerased) BSL will start, detect that there is nothing to do and then jumps to the reset vector (and into the void, as the BSL area is now unaccessible).
    It should, however, still be possible to do a mass erase or jsut flash something else to the device. I wonder why the software throws an error. Maybe the eclipse code is so slow that it after resettign the MSP cannot establish a JTAG connection quick enough before the BSL has jumped to the reset vector. I wonder whether all MSPs can be locked by just writing nonsense (or more precisely, an address that points to vacant memory) into the reset vector.

    If you want the reset vector pointing to something more meaningful (or left alone completely, as it is to be set for the applicaiton and not the BSL), you can alter the linker script for your project, so the reset vector is assumed to be in the BSL area or the info flash or anywhere else where it won't hurt.

    You can go even further and put something at the original reset vector location that results in an endless loop. (e.g. 0xfffc: 0xff, 0x3f, 0xfc, 0xff) This will keep the processor from running wild if you just want to test your BSL and failed to trigger the entry sequence.

  • 0 in reply to Jens-Michael Gross
    Prodigy 60 points

    Thanks for the comments.

    After looking into it some more, it really does sound like the answer is "don't do that". As a warning to others, I used TI's example BSL from the "Creating a Custom Flash-Based BSL" app note (SLAA450). Specifically this is the version for Code Composer Studio. I noticed TI's production BSLs (also in the same zip file) are all designed to work with the IAR compiler and they do move the reset vector to a different location where it can do no harm.

    There may be a small chance of recovering it by writing JTAG code for another MSP430 and running it as fast as possible before the processor resets due to trying to access the protected BSL flash. However, it's not worth my time. We will probably just replace the processors on the target boards and move on.

**Attention** This is a public forum