• State TI Thinks Resolved
  • Locked Locked
  • Replies 9 replies
  • Answers 1 answer
  • Subscribers 79 subscribers
  • Views 514 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.

MSP430FR2476: Help with autoinvoke BSL

Robbie Valentine
Expert 2975 points
Part Number: MSP430FR2476
Other Parts Discussed in Thread: MSPBSL

Hello,

I have an MSP430FR2476 MCU in my product.  I launch the BSL and reprogram it when I need to flash it with new firmware via another MSP that is bigger.  This all works great and I have the BSL commands working fine as well.  The situation I'm stuck in is that I need the MSP430FR part to auto invoke its bsl if the image flash gets screwed up.  

For example, if I have a customer that gets partway through the update and has a brown out or just unplugs the data cable feeding the PCB the image etc...I need to be able to recover.  So what I need is a way to get back into the BSL without any of the MSP430FR's IO interaction.  I don't have access to the RST/TEST pins.  I normally invoke the BSL via a command from a software UI that commands the main processor to send a message to the MSP telling it to invoke it's BSL.  

So I'm struggling with this corner case of how do I re-flash the MSP430FR part if the first attempt at flashing fails for whatever reason.  I've read that this part falls in the category of MSPs that autoinvoke the BSL if the memory is erased.  I'm referring to slau550x "MSP430 FRAM Devices bootloader (BSL)" document from TI.  In section 3.3.3 there is a paragraph about blank detection.  I've attached a screenshot as well of this section.

I can test this very well on my bench so right now I'm erasing the part and rebooting my system.  With a blank MSP430FR2476 I'm attempting to get out of this pickle.  I am trying to send the BSL messages within the 10 seconds that section 3.4 mentions as a timeout feature.  It seems that the BSL never responds.  

Does anyone have any comments or is there a register I need to write to tell the auto invoke feature to execute on power up?  

I'm using I2C as my BSL link and not the UART.  My main processor also configures some other ICs on power up, but they don't share the BSL address of 0x48.  I assume this isn't a problem?

Any help would be greatly appreciated thanks!!

  • 0
    TI__Mastermind 26420 points

    Hey Robbie,

    You may already be aware, but all the BSL related collateral for MSP430, including the document you screen captured here, can be found on the MSPBSL page. 

    I'm trying to understand your issue.  It sounds like you are not invoking the BSL via the hardware entry sequence and it is not currently possible on the board.   Instead, it sounds like you are sending a message to the MSP430 telling it to invoke the BSL via the application software.  Is that all correct?  

    I was not aware of the device automatically entering the BSL if blank and there doesn't seem to be much information.  I'm going to assume that as long as the device has been mass erased or brand new then the BSL will automatically be invocated as stated here and in the datasheet.  

    Questions:

    1. How did you erase the device?  (And how do you plan to do this in this corner case in the field?)
    2. It seems that section 4.1.5.2 in the MSP430 FRAM Devices Bootloader UG shows the sequence that should be sent after a mass erase.  Is this the command that you sent for this test?

    Thanks,

    JD 

  • 0 in reply to JD Crutchfield
    Expert 2975 points

    Hi JD,

    So I've managed to figure out whats going on so far.  It turns out there are select families that launch to BSL on power up if the device is blank and mine is one.  This is great actually.  I was sending the launch BSL command first which seemed to screw things up.  Once I started sending direct commands it worked fine.  The catch is that it the BSL is only available for 10 seconds.  This isn't awesome but still not bad and I now have a decent path forward.

    I don't have access to test and reset pins so if my customer erases the MSP when attempting to load an image, but doesn't actually load the image data, I would have been stuck unable to reflash the device.  That was my original issue.  So it is sort of solved.

    My ultimate problem here now is the following.

    I don't have access to the TEST/RST pins of the MSP, I am invoking the BSL via I2C message from another MCU.  If an image gets loaded and the device is NOT blank (rather a corrupted image or something) is there any way to launch / access the BSL without physical access to the test/reset pins?

    Thanks for your time!

  • 0 in reply to Robbie Valentine
    TI__Mastermind 26420 points

    Hey Robbie,

    Unfortunately, This is the edge case that I was curious about as well.  If a corrupted image gets loaded and prevents the application from invoking the BSL in software, then I don't see another way to invoke it besides externally with the TEST/RST pins.    

    This device will automatically invoke the BSL if blank, but I also don't know of a way to erase a device that would have a corrupted flash image.  (The only exception being to invoke the BSL externally and sending an incorrect password, but if we could already invoke the BSL externally then we don't need to do this.)

    It seems like there is always going to be some risk.  

    Thanks,

    JD

  • 0 in reply to Robbie Valentine
    Genius 4350 points

    It would involve restructuring your code, but you could have the Reset vector always point to code stored in Information Memory, which would be permanent and write-protected even on a mass erase, if that's possible.  That code would first check to see if BSL needs to be invoked, and if not it would jump to the real application (which would always have to begin at the same place).  The invoke test could be the state of a pin (any pin, even one of the I2C pins), or some communication from the master.  Or it might even work to always invoke BSL if the BSL timeout would return control back to the INFO code.

    The other thought is that you don't actually have to mass erase the whole device, you just need to overwrite the reset vector with 0xFFFF, then reset or power-cycle.  I don't know if there's a way to do that.

  • 0 in reply to George Hug
    Expert 2975 points

    Hi George thank you for the response that was very very helpful!!

    Is the information memory even safe from the BSL mass erase?

  • 0 in reply to Robbie Valentine
    Expert 2975 points

    Nevermind - found the answer in the BSL users guide for mass erase message.  It does so it looks like I will need to do a manual erase.

  • 0 in reply to Robbie Valentine
    Expert 2975 points

    Also as an FYI to others - the BSL password requires the top 16 bytes of code space not just the reset vector 0xFFFE.

  • 0 in reply to Robbie Valentine
    Genius 4350 points

    It's not clear to me why it's necessary, or even beneficial, to mass erase an FR part at all.

    Anyway, in the old days with chips like the G2553, you could enter BSL from firmware at a different point, and that would have the effect of preventing erasure of any information memory on a mass erase.  But the new chips don't let you see into the BSL very far, so that's probably not possible.

    Yes, the password is a continuing problem.  In cases like yours when the update has failed, which version of the password should you provide next time?  In other words, which version of the firmware will you be upgrading FROM?

    Well I'm interested in seeing what you come up with for a solution.

  • 0 in reply to George Hug
    Expert 2975 points

    I'll report back - I'm hatching a plan.

    I did find a bug in the BSL documentation - see attached image.

**Attention** This is a public forum