• State Resolved
  • Locked Locked
  • Replies 6 replies
  • Answers 1 answer
  • Subscribers 80 subscribers
  • Views 546 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.

MSP430F5529: Custom BSL not debuggable with IAR and FET-Debugger

Martin Bindrich
Prodigy 20 points

Part Number: MSP430F5529
Other Parts Discussed in Thread: UNIFLASH

Hi,

I have build a custom BSL as described in 'slaa450g' and tried to load it the BSL Flash area with the IAR debugger using the FET430UIF.
BSL-protection on downloading the code is turned off. This fails and I checked thread https://e2e.ti.com/support/microcontrollers/msp-low-power-microcontrollers-group/msp430/f/msp-low-power-microcontroller-forum/1048151/msp430f5438a-ep-command-line-interface-for-programming-msp430-flash-memory/3880772#3880772 about it.

I can confirm that it is not possible, even with Uniflash, to download the BSL-code.

However, flashing the BSL together with my application as described in the thread is possible with Uniflash.

Are there any new insights about the reason of this limitation?

My second question is concerning the debugging, which seems to be completely impossible.

Restarting the IAR and choosing Debug without downloading offers me a view to the programmed BSL section, but only partly.
The memory area from 0x1000 to 106D only returns '---' in the disassembly view.
Breakpoints can be set to various segments of the BSL in the disassembly view (not in the C-code view). But none of them lead to a stop of the debugger.

Is there a general block on debugging the BSL-section?

Best regards,

Martin Bindrich

  • 0
    Guru 34983 points

    I don't know what is your target. If your target is USB BSL, than from my point of view debugging USB by breakpoints is impossible.

    BSL section is locked by default after device restart (similar to info segment A).

    When I was working on CDC BSL (for MSP430F550x, that should work also on MSP430F551x family that 5529 belongs) for development was used main flash (no problem with size limited to 2 KB) and RAM (not BSL segments at all). After start up code was copied from flash to RAM and executed from there, with fast mailbox log (same as UART log). When I was 100% that everything is working fine, code was relocated from main flash to BSL segments. Still after start up it was copied from BSL to RAM and executed from there.

    JTAG fuse is located at the end of BSL segments, so modifying and debugging code there is not my cup of tea.

  • 0
    Prodigy 20 points

    Hi zrno soli,

    Thanks a lot for your fast response.
    Yes, my target is to create a customized BSL for USB communication. I agree moving the BSL code to either application Flash or RAM will also fix my problems.

    However, I just don't understand why debugging within the BSL-code segment is blocked. The debugger can be set to unprotect the BSL. That's why I can see the complete BSL memory (with some ridiculous limitations in the disassembly view). So what is actually blocking the debugging?

  • 0 in reply to Martin Bindrich
    Guru 34983 points

    Don't know about BSL related debugging restriction. What is missing in factory default TI HID BSL, why you need customized version?

  • 0 in reply to Martin Bindrich
    TI__Guru 56685 points

    Hello,

    It is recommended for Custom BSL development to be done in main flash, and only moved to BSL section of memory for final testing/deployment. Debugging straight form BSL memory for development is not supported. See section 1.5 BSL Development and Debug in the CUSTOM BSL App note. 

    Also keep in mind the USB BSL is quite a bit different and complex than other BSL implementations due to USB stack size being greater than 2kB allocated for BSL. USB BSL implementation stores a paired down version of USB stack and BSL implementation in BSL area that is utilized for bring up and first communication to host. The host then downloads a full USBN stack and USB BSL to the RAM of the device for full functionality. If developing a custom USB BSL, it is recommended to only change the RAM BSL portion of the USB BSL. 

  • 0 in reply to Jace H
    Prodigy 20 points

    Hi Jace

    Thanks for the clarification. Chapter 1.5.1 of the custom BSL App doc is a bit ambiguous as in the last paragraph a method to test code in BSL memory is described.
    I'll carry on with testing the BSL code in RAM and when this works move it to BSL memory.

  • 0 in reply to zrno soli
    Prodigy 20 points

    Thanks for your help. I need a customized BSL because on my product securing the BSL via a password is not sufficient.

**Attention** This is a public forum