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.

MSP430F5510 not entering BSL programatically

Other Parts Discussed in Thread: MSP430F5510, MSP-FET

Ok, I'm trying to implement a field-upgradeable firmware process on the above-mentioned MSP430 variant.  The previous engineer had implemented:

//__bis_SR_register(LPM3_bits + GIE); // Go into LPM3; keep ints enabled.
__disable_interrupt(); // Ensure no application interrupts fire during BSL
// This sends execution to the BSL. When execution
// returns to the user app, it will be via the reset
// vector, meaning execution will re-start.
((void (*)())0x1000)(); // BSL0

...but when I do this, Windows XP immediately complains about a malfunctioning USB device (expected), but the BSL programming app from the TI MSP430 software library download keeps telling me it's not connected.  Tried disconnect/reconnect, still no joy.

An un-programmed device performs as expected, so I i know it's not my machine setup.

Comments, RTFMs, Web links?  All help appreciated.

Ed Averill

  • Ed, you might try this as the mechanism for programmatic BSL entry:

    1. Do an SWBOR
    2. Early during reset handling, recognize the cause of the reset was SWBOR (using the PMMRSTIV register for example)
    3. Then jump to 0x1000 instead of starting the application

    This will ensure that the USB module (and perhaps other modules) are in the state expected by the bootstrap loader code.

    Jeff

  • Ok, I see.. I was starting to suspect that some post-boot setup work was interfering with the BSL process.

    Thanks for the suggestions - I'll give it a shot!

  • Hi Edward,

    I wanted to point out the app note "USB Field Firmware Updates on MSP430 MCUs" www.ti.com/lit/pdf/slaa452 in case you had not already seen it. It has a description of different ways you might want to enter the USB BSL in your application, and in your case it sounds like you are using maybe the model from section 4.3. There is also associated code examples with the app note.

    Disabling interrupts and jumping to 0x1000 is correct - however, I wonder if maybe you should be calling the USB disconnect function first? This is mentioned in section 4.3 of the app note.

    One other thing to note, since you said that blank devices work correctly - make sure you haven't somehow erased the BSL area of the part. I'm assuming you are using the default BSL that comes pre-loaded in the device?

    Regards,

    Katie

  • Good morning Katie!

    That's a good idea, and thanks for the link!  I really appreciate the info, the previous engineer didn't document things too well.

    I'll add that functionality and see what happens.,

  • Yes, calling USB_disconnect() prior to jumping off into the BSL seems to have worked - I can now upgrade my device with new firmware vi the USB and the TI BSL_GUI app.

    Thanks to everyone for your assistance!  Have a great rest of the week!

    ..ed..

  • Ok, new problem - I have one unit that programs flawlessly, but on the second one it gets 1/2 way through the programming process and Windows pops up a nasty message "A USB device has malfunctioned" and the BSL app says "cable diconnected" - the device ends up in a scrambled state and I have to reprogram via IAR.

    Anyone have any idea what's going on?

  • I encountered a similar issue with the BSL on the MSP430F5510. USB BSL on a blank device worked 100% of the time, but entering the BSL from the application was hit-or-miss despite following all the reccomendations in the USB API programmer's guide. When it didn't work, it would not enumerate as a HID device and Win7 would complain about a malfunctioning USB device.

    In case it helps anyone else, the fix for me was to change the DCO speed from 24MHz down to 8MHz (and wait for it to stabilize) prior to calling the BSL.

    Tim
  • Tim,

    Thank you so much for pointing this out - I'll have to do some testing and look at the BSL source but I'd guess the problem is likely that the BSL may be setting Vcore at a lower level than can support 24MHz, in which case we should add your lowering to 8MHz recommendation to www.ti.com/lit/pdf/slaa452 software entry procedure steps. Thanks for flagging this.

    Regards,
    Katie

  • Tim,

    What revision of F5510 were you using? I will need to know in order to know which BSL version was in the parts.
    -Katie
  • Katie,

    The F5510 parts I am working with are all Rev D silicon, 48 pin RGZ package.

    Tim
  • Hi Tim,

    As an experiment, can you take a known failing device, and replace the BSL with the latest USB BSL version from www.ti.com/lit/zip/slaa450? You can find it in SLAA450/5xx_6xx_Released_BSL_Images/MSP430F552x_550x_Family/USB BSL. The file is BSL.00.07.88.38.txt - you should be able to load it with an MSP-FET and Elprotronic FET-Pro430 Lite software. You'll need to go into Setup > Memory Options to select it to program the BSL area.

    Then try testing it with your software jump - does the issue persist in the same way as before?

    Regards,

    Katie

  • Katie,

    Yes, the jump to BSL fails with the newer BSL.00.07.88.38 when the application is running with 24MHz DCO.

    Thanks,

    Tim

**Attention** This is a public forum