MSP430F5526: RAM BSL is not writing application code to flash

Jason Gramse

Part Number: MSP430F5526
Other Parts Discussed in Thread: MSPBSL

We have a small USB sensor that uses the MSP430F5526. We rely on the bootloader to program new boards as well as to update firmware should the need arise. Our program uses the python source code (with a few modifications to fix a few timing issues) given in the bootloader example code. We have had these in production for approximately 3 years without any problems. Lately, the application is not being successfully written to flash memory. Initializing the factory BSL works, writing the RAM BSL works, re-enumerating to the RAM BSL works, and the RAM BSL appears to accept the commands sent to it with no problems. If I send an unsupported command like TX_DATA_BLOCK, it responds with the correct error code 7 for unknown command.But for whatever reason, the flash memory is not being written. Has anyone seen this before or knows how to fix it?

It may be helpful to know that the MSP430 USB Firmware Upgrade Example v1.3.1 output is:

Sending RAM BSL v00.07.08.38
Done RAM BSL v00.07.08.38
USB device was unplugged!
Unsuccessful in starting the BSL. Restarting.
USB device was unplugged!

However our custom script seems to have no problem starting the RAM BSL. I believe this is because we allot additional time for re-enumeration after the ram bsl has been written. I have also tried the newer version of RAM BSL v00.08.08.38 with the same results.

over 7 years ago

0 Arthi Bhat1 over 7 years ago

TI__Expert 6760 points

Hello Jason,

Have you actually verified that the FLASH is not being written to by reading back the content after it has been updated? You can use the MSP430Flasher tool to read back memory content.

Just for my clarification, was the MSP430 USB Firmware Upgrade Example v1.3.1 tool customized or the python based tool? The MSP430 USB Firmware Upgrade Example v1.3.1 downloaded from TI website is not python based...so I am a little confused here.

Also is it possible to send the entire output listed in the MSP430 USB Firmware Upgrade Example v1.3.1 tool? It should have something like this:

Starting

Mass erase occurred!

Password sent Successfully

Sending RAM BSL v00.07.08.38

Done RAM BSL v00.07.08.38

Sending Blink LED code

Firmware Sent

Memory successfully verified

Total programming time is 93ms

If you are not seeing the FLASH written to, you can check a couple of things:

1) Are you sending the correct password?

2) Are you writing up to byte boundary? This might not cause the issue you are indicating but it might be worth checking.

Regards,

Arthi

0 Jason Gramse over 7 years ago in reply to Arthi Bhat1

Intellectual 410 points

Thank you for the reply Arthi

Arthi Bhat1 said:
Just for my clarification, was the MSP430 USB Firmware Upgrade Example v1.3.1 tool customized or the python based tool?

It's a customization of the python based tool, which I found in MSPWare_3_20_00_37\usblib430\Host_USB_Software\Python_Firmware_Upgrader\python-msp430-tools

Arthi Bhat1 said:
Have you actually verified that the FLASH is not being written to by reading back the content after it has been updated?

Yes, I've used the Lite FET-Pro430 tool to read back the memory and it is all 0xFF, except for a few bytes in the info memory segments and the bootloader area starting at 0x1000.

Arthi Bhat1 said:
Also is it possible to send the entire output listed in the MSP430 USB Firmware Upgrade Example v1.3.1 tool?

Here is the entire output.

Starting
Password Sent Successfully
Sending RAM BSL v00.07.08.38
Done RAM BSL v00.07.08.38
USB device was unplugged!
Unsuccessful in starting the BSL. Restarting.
USB device was unplugged!

It does this for the Blinky example code as well.

Arthi Bhat1 said:
1) Are you sending the correct password?

The password is initially sent incorrect as 30 bytes of 0xff and 2 bytes of 0x00 to trigger a mass erase of the flash memory. After that, the password of 32 bytes of 0xff is sent and is accepted without error.

Arthi Bhat1 said:
2) Are you writing up to byte boundary?

I don't know what you mean by writing up to the byte boundary. But the starting address I'm writing to is 0x4400 and there are 19898 bytes of application code. I'm also writing 46 bytes of data to address 0xffd2 which I think it the reset vector.

Something else to add. The problem we are having is not ALL the time / every board. In fact last week we built up 25 of them and none of them had any issues. This week we built up 25 more and every single one of them has the problem. Same manufacturing employee, work station, procedure, batch of boards, even USB port was used. And it's been off and on like this for about a month though it's not always one batch is good one batch is bad. Sometimes it's 10-15 bad in the group. In other words, the problem is intermixed but only started showing up in the last month or so out of 3 years of manufacturing.

0 Arthi Bhat1 over 7 years ago in reply to Jason Gramse

TI__Expert 6760 points

Hi Jason,
I am not sure what is going on. So if the tool is listing the messages correctly, it looks like to the tool that you unplugged the USB cable while it is in the process of downloading the firmware. Does this cause any issues in the board like bricking? On the failed board, are you able to try and download BSL again and does it work the second time?

You indicate that you have changed or added some timing parameters. You might try adjusting the time at the point where the tool is downloading the firmware or before it sends the re-start command.

Regards,
Arthi

0 Jason Gramse over 7 years ago in reply to Arthi Bhat1

Intellectual 410 points

I can still use the same board over and over with the same results. We have also checked voltage levels during the programming to monitor whether or not the board loses power which could simulate a disconnect, but the voltage levels stay constant throughout the process.

In the python tools, I have added 5 seconds of delay after the code sends the LOAD PC 0x2504 command and 2 seconds after it closes the connection before reopening again (presumably in the RAM BSL at this point).

I'm wondering if it's the RAM BSL that is not starting correctly. In slau319 it states that "BSLs that are programmed in flash and that communicate by USB contain only a subset of the commands", "RX DATA BLACK FAST, RX PASSWORD, and LOAD PC". This works out to be true as the BSL sends back error code 7 if any other command is sent. However, it also says that the RAM BSL is a "full-featured BSL". Am I correct to assume then that the RAM BSL should respond to all BSL Core Commands? If so, then the RAM BSL is either isn't started correctly, or never actually written to RAM because I can't send any commands besides the 3 that are supported for the USB flash BSL. In fact in the provided python tool, I've had to comment out the line requesting the BSL_VERSION because it returns an unkown command error code. As the flash BSL is RAM write only, it would be consistent with the problems I am seeing.

Is there anything that would cause the flash BSL to not write to RAM properly?

0 Jace H over 7 years ago in reply to Jason Gramse

TI__Guru 56685 points

Jason,

the USB RAM BSL is full featured, while the USB BSL on the device is used to load the RAM version basically. I would say you are having issues getting the RAM BSL started properly. Can you try using the BSLScripter with one of the USB BSL examples to test things out?

0 Jason Gramse over 7 years ago in reply to Jace H

Intellectual 410 points

It appears to have worked...? Here is the output of the log file. My board doesn't have an LED to blink with the Blinky program but it no longer responds to the BSL-Scriptor so I would assume that it is running the correct code. And reading the memory back with FET Pro430 tool there is indeed new code written to flash.

BSL Scripter 3.3.0
PC software for BSL programming
2018-Apr-12 13:16:19
---------------------------------------------------------
Input file script is : C:/ti/msp430/MSPBSL_Scripter_win/Example/5xx_usb/script_5xx_usb.txt
////////////////////////////////////
//Write RAM USB BSL to the device
////////////////////////////////////
MODE 5xx USB
//gives wrong password to do
//mass erase in the memory
RX_PASSWORD pass32_wrong.txt
Read Txt File : C:\ti\msp430\MSPBSL_Scripter_win\Example\5xx_usb\pass32_wrong.txt
[ERROR_MESSAGE]BSL Password is error!
RX_PASSWORD pass32_default.txt
Read Txt File : C:\ti\msp430\MSPBSL_Scripter_win\Example\5xx_usb\pass32_default.txt
BSL Password is correct!
RX_DATA_BLOCK_FAST RAM_BSL_USB.txt
Read Txt File : C:\ti\msp430\MSPBSL_Scripter_win\Example\5xx_usb\RAM_BSL_USB.txt
Time elapsed of writing 3328 bytes : 0.109 seconds
Speed of writing data :29.81(kB/s)
SET_PC 0x2504
DELAY 3000
Delay 3000 ms
////////////////////////////////////
//Start the RAM USB BSL application
//to download the blink application
////////////////////////////////////
MODE 5xx USB
RX_PASSWORD .\pass32_default.txt
Read Txt File : C:\ti\msp430\MSPBSL_Scripter_win\Example\5xx_usb\pass32_default.txt
BSL Password is correct!
RX_DATA_BLOCK .\blinkLED_f5529.txt
Read Txt File : C:\ti\msp430\MSPBSL_Scripter_win\Example\5xx_usb\blinkLED_f5529.txt
Time elapsed of writing 230 bytes : 0.023 seconds
Speed of writing data :9.765(kB/s)
SET_PC 0x4400

0 Jace H over 7 years ago in reply to Jason Gramse

TI__Guru 56685 points

Hello Jason,

I would confirm if you can that P1.0 is being toggled with a logic analyzer or scope if you have the ability to. That being said, if it has been downloading correctly, then we can conclude that your HW and connection to your PC are just fine.

Can you do a fresh install of the Python FW Updater with no modifications and see if the examples work as well?

0 Jason Gramse over 7 years ago in reply to Jace H

Intellectual 410 points

Success! Sort of... I have indeed been able to flash my application code using the fresh install of the Python FW Updater. I have also modified it to fit into my PC Software and have successfully flashed application code there as well. The problem now arises when I try and jump to the bootloader from application code. Again something that used to work flawlessly, no longer does. Here is the code I'm using to perform the jump.

void jumpToBSL(void)
{
TB0CCR0 = 0;
TB0CTL = 0;

__disable_interrupt();
USBKEYPID = 0x9628; //set KEY and PID to 0x9628 -> access to
USBCNF &= ~PUR_EN; //disconnect pull up resistor - logical
//disconnect from HOST
USBPWRCTL &= ~VBOFFIE; //disable interrupt VUSBoff
USBKEYPID = 0x9600;

__delay_cycles(500000);
((void (*)())0x1000)(); // Call BSL
}

The device does disconnect properly but then re-enumerates itself using my application code, not in the BSL.

0 Arthi Bhat1 over 7 years ago in reply to Jason Gramse

TI__Expert 6760 points

Hi Jason,

Can you replace the entire code in your function jumpToBSL() with the following and see if it works for you:

     USB_disconnect ();   //Sets PUR pin to high-impedance (clear PUR_EN in USBCNF), disables
                          //the VBUS "going OFF" interrupt (clear BVOFFIE in USBPWRCTL)
   USB_disable();       //Disables USB module (clear USB_EN in USBCNF) and disable PLL (clear
                          //UPLLEN in USBPLLCTL).
     //__delay_cycles(2); //If need delay.

     ((void (*)())0x1000)();   //jump to BSL

Regards,

Arthi

0 Jason Gramse over 7 years ago in reply to Arthi Bhat1

Intellectual 410 points

No luck. It always starts up in application code instead of the bsl. And it doesn't matter how long the delay is before I call the BSL. I've tried 1 cycle up to 5 seconds and still starts up in application code. In section 3.8.1 of Using_the_BSL.pdf there it says:

"TI recommends clearing the configuration of any module registers that are used in the BSL application,
because the configuration for the external application can interrupt the BSL application and cause
unexpected behavior. One example is that in the USB BSL, the Timer_B module is used in clock
initialization. If Timer_B is also used in the external application, this might cause a failure in BSL
initialization. "

We are using Timer A and Timer B (which I was clearing in the original jumpToBSL function) and UCB0 for SPI communications. We are using a 4 MHz crystal on XT2 and clocks are initialized at 8 MHz.

There's also a mention of:

"Memory location 0x1002 contains a jump to the "BSL Action" function. To invoke the action function, three
parameters are needed. The first parameter is a number describing which function, the second two are
simply known values to indicate that the function was called intentionally.
R12: The function number
R13: 0xDEAD
R14: 0xBEEF"

I don't think this applies in my case, but I tried loading R13 and R14 anyway and still no luck.

0 Arthi Bhat1 over 7 years ago in reply to Jason Gramse

TI__Expert 6760 points

Jason, what starts up in application code instead of BSL? Does this mean you are not able to Jump to location 0x1000 from you main application?

Once the application code jumps to BSL, the device should be in BSL mode and then you can use the Python Firmware Upgrader tool to download FW. Once the FW is downloaded, the Python Firmware Upgrader tool will do a reset of the device and the main application will start running.

Regards,
Arthi

0 Jason Gramse over 7 years ago in reply to Arthi Bhat1

Intellectual 410 points

Yes I am not able to Jump to location 0x1000. The device disconnects properly from USB but once I attempt to execute the call to BSL, it restarts back in main of my application. Windows Device Manager recognizes the device using my USB VID and PID instead of the BSL 0x2047 and 0x200. My software connects with the device and begins reading data as normal.

0 Arthi Bhat1 over 7 years ago in reply to Jason Gramse

TI__Expert 6760 points

Okay, so how are you calling jumpToBSL() function from your application? Ideally, you should be calling it when a user sends a prompt from a terminal window because BSL updates are done when updates are available. Once the prompt is received, your application should then check for that prompt in your code and then jump to BSL. If that prompt is not there then is sits in the while loop doing its thing.

If you don't have the prompt but the jumpToBSL() is part of your main application, I believe you will see what you are seeing currently.

If you need an example of how to interact with the user then in the MSP430USBDevelopersPackage there is a CDC example called 'C1_LedOnOff you can modify/look through to see how this is done.

The example can also be downloaded from CCS menu View->Resource Explorer Classic.

Regards,
Arthi

0 Jason Gramse over 7 years ago in reply to Arthi Bhat1

Intellectual 410 points

Yes I am waiting for a prompt from the user. If the current software detects that the sensors firmware is out of date, the user is notified and prompted to update. Or we can activate it manually. Either way, the command 0xaa 0x21 is sent to the sensor which then calls jumpToBSL(); Once in BSL mode, then we load the RAM BSL followed by loading the latest firmware.

The function is being called properly, it's just not making it into BSL mode.

0 Arthi Bhat1 over 7 years ago in reply to Jason Gramse

TI__Expert 6760 points

Okay then, maybe the Timers are an issue as you indicated. Can you comment out the timers in your main application and see if this will allow the code to jump to BSL? If that cannot be done, then there is an API in driverlib you can use to stop the Timer:

Timer_A_stop()

There should be one for Timer B also. Maybe you can call these APIs before you disconnect and disable USB in the jumpToBSL() function.

Regards,
Arthi

0 Jason Gramse over 7 years ago in reply to Arthi Bhat1

Intellectual 410 points

I found it! The timers weren't causing the problem. I tried not initializing them at all, tried not initializing any modules except for USB and the problem was still there. The problem was the last line of this interrupt:

/** ======== UNMI_ISR ========*/

#pragma vector = UNMI_VECTOR
__interrupt void UNMI_ISR(void)
{
switch(__even_in_range(SYSUNIV, SYSUNIV_BUSIFG))
{
case SYSUNIV_NONE:
__no_operation();
break;
case SYSUNIV_NMIIFG:
__no_operation();
break;
case SYSUNIV_OFIFG:
UCS_clearFaultFlag(UCS_XT2OFFG);
UCS_clearFaultFlag(UCS_DCOFFG);
SFR_clearInterrupt(SFR_OSCILLATOR_FAULT_INTERRUPT);
break;
case SYSUNIV_ACCVIFG:
__no_operation();
break;
case SYSUNIV_BUSIFG:
// If the CPU accesses USB memory while the USB module is
// suspended, a "bus error" can occur. This generates an NMI. If
// USB is automatically disconnecting in your software, set a
// breakpoint here and see if execution hits it. See the
// Programmer's Guide for more information.
SYSBERRIV = 0; //clear bus error flag
USB_disable(); //Disable
USB_enable();
USB_connect();
//WDTCTL = 0x1; // intentional write without password. generates PUC to reset device.
}
}

After commenting this out, the bootloader starts up great! This must have been getting called before the interrupts were disabled. I had it in there just to reset the sensor if something were to happen here. I don't know why it wasn't an issue before (maybe it was and just wasn't tested thoroughly enough).

Thank you very much for help.

0 Jason Gramse over 7 years ago in reply to Arthi Bhat1

Intellectual 410 points

I'd like to give you credit for your help so I'm going to mark your last reply as 'This resolved my issue'. Thanks again!

0 Jason Gramse over 7 years ago in reply to Arthi Bhat1

Intellectual 410 points

I spoke to soon. It works while debugging in CCS, but it does NOT work otherwise....

0 Jason Gramse over 7 years ago in reply to Jason Gramse

Intellectual 410 points

After scouring the forum for more ideas I came across this post:

e2e.ti.com/.../2420855

After increasing the 3V3 decoupling capacitor to 22uF, they are now successfully jumping to BSL from application code.

**Attention** This is a public forum

MSP low-power microcontrollers

MSP low-power microcontroller forum

MSP430F5526: RAM BSL is not writing application code to flash