• State Resolved
  • Locked Locked
  • Replies 10 replies
  • Answers 2 answers
  • Subscribers 79 subscribers
  • Views 938 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.

MSP430G2433: Flashing with BSL from host controller

Cedric Gerber
Expert 2240 points
Part Number: MSP430G2433
Other Parts Discussed in Thread: CC3200, MSP-FET, MSP-FLASHER

Hi, 

I'm trying to program the msp430G2433 with BSL from a host controller (CC3200) and have a few issue.

I have successfully implemented the BSL communication as shown in this document http://www.ti.com/lit/an/slaa755/slaa755.pdf.

When reading address 0x0FF0 from the host, it shows the correct information (device: 2553, bsl version: 0203), which is a good start ;)

As the host will have to program both new msp and already programmed msp, I was hoping to make something like: 

  1. Mass erase (or RX password with a bad password which shall also trigger a mass erase)
  2. RX password with default FF...
  3. Send new firmware

But after having sent a first bad password, which I suppose triggered a mass erase, I am not able to make the msp work normally anymore. It also does not work when flashing it with our production firmware using the MSP-FET + MSP430Flasher 1.3.18 which makes me think something else than the code part has been modified.

Question 1:

What did change and how can I restore it? Can it be related with the erasure of the protected information memory? https://e2e.ti.com/support/microcontrollers/msp430/f/166/t/110438?MSP430-Restore-Flash-Protected-Information-Memory-to-Factory-Settings

Question 2:

What is the best way to program both brand new msp and already programmed msp with BSL?

I hope my questions make sense, I'm quite new with the msp430 ;)

  • 0
    TI__Guru 56685 points
    Hello Cedric,

    From the BSL perspective, the BSL does not care if the device has been programmed or not. Also, locking Info Memory should not prevent you from programming the whole device via BSL or JTAG/SBW.

    That being said, since you are going through production programming, you could have the e-fuse blown for JTAG which would prevent JTAG interaction with the device. There is no way to reverse this on this device. Please double check your production flow to see if you blow the e-fuse to lock the JTAG.

    Also keep in mind that both the tools and connections sued are different between the BSL and JTAG/SBW. the MSP-FET is capable of doing both, but the MSP-Flasher only does JTAG.SBW, while a similar program called the BSL-Scripter does BSL. Also, the physical connections from the device to the MSP-FET are different. Please double check your connections on both the MSP-FET side as well as the MSP430 side to ensure you are using the right connections for the programming interface you are trying to use.
  • 0
    Guru 33653 points

    Cedric Gerber said:

    But after having sent a first bad password, which I suppose triggered a mass erase, I am not able to make the msp work normally anymore. It also does not work when flashing it with our production firmware using the MSP-FET + MSP430Flasher 1.3.18 which makes me think something else than the code part has been modified.

    By sending wrong password, BSL (by default) also erased (protected) info A segment with factory preloaded constants. This is the reason why your device (even reflashed by MSP-FET) does not work. DCO can be restored by 32kHz crystal and TI open source example (download software examples from device tools & software tab, slac485 software examples zip) msp430g2xx3_dco_flashcal.c. I guess that ADC constants (if they exists) can not be recovered.

    There is option (check family guide or slau319) to disable auto erasing info segment in new BSL versions (related to G series), so factory constants will bot be erased due to wrong BSL password.

  • 0 in reply to Jace H
    Genius 4350 points

    Jace H said:
    Hello Cedric,
     
     
    Also keep in mind that both the tools and connections sued are different between the BSL and JTAG/SBW. the MSP-FET is capable of doing both, but the MSP-Flasher only does JTAG.SBW, while a similar program called the BSL-Scripter does BSL.

    I believe the G2433 would use BSLDEMO, not BSL-Scripter.

  • 0 in reply to zrno soli
    Genius 4350 points

    zrno soli said:
    Cedric Gerber

    But after having sent a first bad password, which I suppose triggered a mass erase, I am not able to make the msp work normally anymore. It also does not work when flashing it with our production firmware using the MSP-FET + MSP430Flasher 1.3.18 which makes me think something else than the code part has been modified.

    By sending wrong password, BSL (by default) also erased (protected) info A segment with factory preloaded constants. This is the reason why your device (even reflashed by MSP-FET) does not work. DCO can be restored by 32kHz crystal and TI open source example (download software examples from device tools & software tab, slac485 software examples zip) msp430g2xx3_dco_flashcal.c. I guess that ADC constants (if they exists) can not be recovered.

    There is option (check family guide or slau319) to disable auto erasing info segment in new BSL versions (related to G series), so factory constants will bot be erased due to wrong BSL password.

    But even if you prevent the mass erase on a bad password, you still have the problem of INFOA if you use the mass erase command.  I don't know if BSLDEMO will work with the controller you're using, but it has a command line option to restore INFOA after doing a mass erase command.  It reads the contents of INFOA, then does the mass erase, then writes it back.  It's not totally reliable though, because the restore may never take place after the erase if there's an error, such as having a bad firmware filename in the command line.  I wish it would do the restore immediately after the erase, but it's deprecated software, so not likely to be fixed.
  • 0 in reply to George Hug
    Expert 2240 points

    Hello,

    Thank you all for your responses!

    @ Jace: I do not blow the jtag fuses in production, both BSL and JTAG interfaces work fine. 

    @zrno  and George: 

    I'll try to restore the DCO with the script and report here. [EDIT]: After running the DCO flash cal, the production firmware works again.

    Is there a way to recalibrate the ADC as well? 

    Is there a way to erase main memory but not INFOA on bad password? (Other than the warm start discussed in slau319, or a custom BSL). Or a way to not require any password?

    That would be the easiest solution for my application, no risk of bricking the device, no risk of confusion of FW.  Note: security is not an issue as the msp is just the slave controller and cannot do much.

  • 0 in reply to Cedric Gerber
    TI__Guru 56685 points
    Cedric,

    As George Suggested, this part needs the BSLDEMO scripter not BSL-Scripter. It is located in the Deprecated folder within the BSL-Scripter download. Sorry for the confusion there.

    That being said, this family of devices do have some limitations. Please see the following E2E Thread for some additional information. e2e.ti.com/.../2391785

    InfoA for this part does have a lock to prevent from erasing, and the BSL will skip over sections of memory that are locked when doing a Mass Erase. However, this device's BSL when starting up form a cold boot, will unlock InfoA when it starts up. A "warm boot" does not unlock InfoA upon BSL startup.

    As the others suggested, you can get your DCO constants back using a code example TI provides and an external Xtal. I believe we also provide an ADC calibration routine within our example code for the part. If not, we do describe a routine within the ADC section of the User Guide.

    Unfortunately, this particular device family is limited on BSL options as even a Custom BSL is not an option for this part. This is due to the fact that the BSL is done in ROM and cannot be changed. If you do need a custom BSL solution, then you can do an application side BSL with MSPBOOT.
  • 0 in reply to Cedric Gerber
    Genius 4350 points

    Cedric Gerber said:

    @zrno  and George: 

    I'll try to restore the DCO with the script and report here. [EDIT]: After running the DCO flash cal, the production firmware works again.

    Is there a way to recalibrate the ADC as well? 

    Is there a way to erase main memory but not INFOA on bad password? (Other than the warm start discussed in slau319, or a custom BSL). Or a way to not require any password?

    That would be the easiest solution for my application, no risk of bricking the device, no risk of confusion of FW.  Note: security is not an issue as the msp is just the slave controller and cannot do much.

    I don't know about the ADC.  You could copy those values from another chip, and hope for the best, but it might be better to just replace the chip, and copy its INFOA to your PC just in case it gets erased.

    I think the answer on erasing all but INFOA is no you can't.  I wrote a long-winded PDF that deals with this beginning on page 3, and it discusses the various options for overcoming the password issue:

    https://github.com/gbhug5a/MSP430-BSL

    I think the bottom line is if you are going to enter BSL at the cold start on boot, you can prevent a bad password mass erase by writing 0000 to 0xFFDE, but you can't actually do anything useful without knowing the password.  You could use the segment erase on MAIN, but that's a protected command, so again you need the password.  I believe TI designed it this way deliberately - without asking me first.  :-)   Maybe zrrno has a better answer.

    But look through the options in my PDF.  You may find that they aren't too burdensome.  My favorite is pointing all the password vectors to an intermedate jump table.  The contents of the jump table change from version to version, but the password block never changes.  So you always know what it is.  But there's also a warm start option with the required boot code fitting into the unused part of INFOA.

  • 0 in reply to George Hug
    Expert 2240 points

    Thank you for the link to the pdf, it does help! 

    I'll give a try to the intermediate jump table.

  • 0 in reply to Cedric Gerber
    Genius 4350 points

    The jump table uses at most 64 bytes, but probably a lot less, but it does add the excution time of the jump to each interrupt processing routine.  That may matter in some cases.

    You may also want to try out the special boot code located in INFOA.  I provide the installer for that for the G2553, and it would let you initiate BSL without even connecting DTR ot RTS, or at least not RTS, and enter BSL with INFOA protected.  For the G2433, I would need to make modifications to the installer to reflect its beginning MAIN address.  Let me know if you need that.

  • 0 in reply to George Hug
    Expert 2240 points

    Thanks for offering the boot code in INFOA! I won't be needing it as I would more likely implement a method to switch to BSL with an I2C command (as the host normally use the I2C to communicate with the msp). I might also send the interrupt vector with I2C. 

    I'll have to characterize our application in details to see if the added delay of the jump table is acceptable or not, as it would be much cleaner not to depend on the msp application to update the msp code.

**Attention** This is a public forum