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

Custom BSL for MSP430F6736 without the entry sequence invocation method.

Sumant Arora
Prodigy 40 points


Hello,

I need to modify the existing BSL for MSP430F6736 series chip to a USCI UART based one Basically I wanted to get rid of the entry sequence to invoke the BSL. I want to use the UART peripheral to invoke the BSL from a user application instead of the entry sequence by using JTAG pins.the user then will send an updated application through host pc via BSL. I have gone through the slaa450c , slau319h and slaa600a and a few discussion threads on this forum as well.I understand that we hv to make a few changes in the source code of the default BSL and make it use USCI UART.Apart from this I believe that using these 2 statements enables us to invoke the BSL from an application-

__bic_SR_register(GIE);
((void (*)(void))0x1000)();

Am I on the right track? What I am lacking is the source code for the default BSL for 6736 family.Do I have to use the released source codes of 5438a and other families as part of slaa450c and change them for use with 6736?If yes then what specific changes need to be made in the bsl source code of another family to port it to the 6736 family.

What all things need to modified to achieve this. I am using the MSP-TS430PZ100B  development board with 6736A  for this customization. I am using ccs 6.0.0.

Thanks

  • 0
    TI__Guru* 79301 points

    Hi Sumant,

    It sounds like you are well on the right track.

    Sumant Arora said:
    What I am lacking is the source code for the default BSL for 6736 family.Do I have to use the released source codes of 5438a and other families as part of slaa450c and change them for use with 6736?If yes then what specific changes need to be made in the bsl source code of another family to port it to the 6736 family.

    I think this is what you are going to have to do, as I do not believe we have a released source code for the BSL for this family. If I were you, I would start with the F5438A BSL source code project for CCS that is included in the www.ti.com/lit/pdf/slaa450 zip file download, in the folder 5xx_6xx_Example_BSL_Source. (another option would be to use IAR or IAR Kickstart and use the many example projects in the 5xx_6xx_BSL_Source folder as your examples - since there are multiple device projects there it should provide good clues about what has to change when you switch the device or peripheral interface PI layer).

    You will of course need to change the project setting to use the device you are using. In your code, there are a few things that I can think of that you will need to alter for F6736:

    1. Look at the linker command file included with the example project for F54xxa, and compare it to the default linker command file for F54xxA. Note all the changes (added sections like ZAREA and how much space they take up). You will need to make these same changes to your F6736 linker command file.
    2. To switch the BSL to using the USCI module instead of the Timer A module, you'll need to change out the PI (peripheral interface) layer of the code. You can find the USCI PI files in the folder 5xx_6xx_BSL_Source/Peripheral_Interfaces.
    3. You will need to change any device specific changes - for example, which USCI module you want to use, which pins on the device need to be setup to use that particular module, etc.

    I hope this helps get you started - there may be a few other changes needed but these should be the big ones. As you mentioned, there are some other similar posts out there - I know there are a couple of threads about how to use the USCI PI layer instead of the Timer A based UART, that might be helpful.

    Regards,

    Katie

  • 0 in reply to Katie Pier
    Prodigy 40 points

    Hi Katie,

    Thank you for a quick response.I will try to implement what you have suggested and see if I am able to get it to work.

    Another doubt that I have is what happens if power is interrupted while the BSL is updating the application code (say through a GUI host application or through BSL_Scripter)?When power is resumed,does the device start in BSL mode?If not,then,since the BSL may already have erased the original application which was initially used to invoke the BSL, how do I invoke the BSL again?I do not have to use the hardware entry sequence using RST and TEST pins since the device is supposed to be used for field upgrades through UART only.

    Thanks and Regards,

    Sumant

  • 0 in reply to Sumant Arora
    TI__Guru* 79301 points

    Hi Sumant,

    The RST/TEST entry sequence is typically there as the entry process so that you do not have to worry about a failed load, since it does not depend on any code in the application area.

    One way around this that you can use is the method that the USB BSL uses - you can modify the BSL so that instead of checking for the RST/TEST entry sequence, it checks whether the reset vector is blank (0xFFFF at reset vector address 0xFFFE). Then, if you always erase the segment with the reset vector first, and write the reset vector as the last part of your load, if there's an interruption any time in between the reset vector should be blank so on reset you'd enter BSL again.

    You can find the line in the F5529 BSL that does this checking, by looking in 5xx_6xx_BSL_Source\MSP430F552x_USB\BSL430_Low_Level_init.s43. The checking is in the BSL_Protect function, and looks like this:

                  cmp.w   #0xFFFF,   &0xFFFE        ; otherwise, test for blank RESET
              jne     JUST_RETA                ; if not blank, skip delay and start

    You could add the same type of checking to the BSL protect function in your code.

    Now, note that this won't help you if you load your code image successfully, but had loaded the incorrect code file (if you load a code file that doesn't have any jump to BSL in it). Then you might still get yourself into trouble.

    Or you can always come up with your own criteria that you want the BSL_Protect function to check, but it has to be relatively simple/quick like checking an IO or checking an address.

    Hope this helps,

    Katie

  • 0 in reply to Katie Pier
    Prodigy 40 points

    Hi Katie,

    Thanks again for the prompt reply.

    I do not understand the following statement-

    "Then, if you always erase the segment with the reset vector first, and write the reset vector as the last part of your load, if there's an interruption any time in between the reset vector should be blank so on reset you'd enter BSL again."

    How do I ensure that on issuing an erase command the reset vector is erased first?And how do I write the reset vector as last part of the load?

    I know these seem like trivial and stupid doubts but I am new to MSP programming and would highly appreciate it if you can guide me further on this issue.Meanwhile I would continue to work on the source of BSL for 6736 and 6779.

    Thanks and Regards,

    Sumant

  • 0 in reply to Sumant Arora
    TI__Guru* 79301 points

    Some of this is controlled by whatever will be your BSL host and what commands it sends to the MSP. I would say always do a mass erase first (which you will need to do anyway) and your reset vector will be blank. Then, when you are loading a new main application area file, always write the address 0xFFFE last - this will of course be controlled by your host and what it sends to the device. For example, on the PC there is the BSL_Scripter application already in SLAA450 download - this scripter program can load from a TI-txt file in the order the addresses are written in the file. So if you use BSL scripter, simply make sure that the data for 0xFFFE address is at the end of the TI-txt file so it will be written last. If, ultimately, your goal is to have some other BSL host (another MCU for example) then you will need to write  your host firmware accordingly to send this last.

    Regards,

    Katie

  • 0
    Guru 227245 points

    If you modify the entry sequence, you won’t be able to force a BSL update using the available tools, as these will always reset the device and do the entry sequence. Which will reset the already application-started BSL and then won’t enter it.

    What Katie meant is that when you always enter the BSL if the reset vector is empty, then you can do an erase of the vector table segment (or a mass erase) first, which either fails (in this case, the application is still there and you can start over) or the reset vector is empty, which will start the BSL after a reset, even if the process was interrupted the first time (e.g. a power failure). Just ensure, that the vector table segment is the last thing you write, so it stays empty until everything else is done.

**Attention** This is a public forum