MSP432E401Y: RTOS Application firmware upgrade

Hello Charles,

Thanks for the suggestion. We have a query

In non-RTOS application, the vector table is placed at the start of the application address.

However, in an RTOS application, the reset vectors are kept at the application's starting address, while the .vecs section is placed at 0x20000000.

In this case, which address should be considered as the VTABLE_START_ADDRESS?

Akash S said:

In this case, which address should be considered as the VTABLE_START_ADDRESS?

What is this file? Why do you need to change it?

See below steps I do and I'm able to run an RTOS application that is linked to 0x4000. 

1. I import the boot_serial_uart_flash_MSP_EXP432E401Y_nortos_ccs project as the bootloader. This bootloader example expects the application to start at 0x4000. You can use other bootloader examples if you want. 

2. I import the buttonled_MSP_EXP432E401Y_tirtos_ccs application project into CCS. After import, it will automatically also import the tirtos_builds_MSP_EXP432E401Y_release_ccs dependency project. The tirtos_builds_MSP_EXP432E401Y_release_ccs has the configuration for the TI-RTOS kernel. 

3. In the tirtos_builds_MSP_EXP432E401Y_release_ccs, I modify the release.cfg and the only thing I do is to add the below line. 

m3Hwi.resetVectorAddress = 0x4000;

 4. In the buttonled_MSP_EXP432E401Y_tirtos_ccs, the only thing I modify is the .cmd file where I map the FLASH to start at 0x4000. I didn't change anything else. 

/*
* ======== MSP_EXP432E401Y_TIRTOS.cmd ========
* Define the memory block start/length for the MSP_EXP432E401Y M4F
*/
--stack_size=1024 /* C stack is also used for ISR stack */

HEAPSIZE = 0x20000; /* Size of heap buffer used by HeapMem */

MEMORY
{
FLASH (RX) : origin = 0x00004000, length = 0x000FC000
SRAM (RWX) : origin = 0x20000000, length = 0x00040000

5. After both boot_serial_uart_flash_MSP_EXP432E401Y_nortos_ccs and buttonled_MSP_EXP432E401Y_tirtos_ccs are built, I use the Uniflash to load both the .out files simultaneously. 

6. After both the bootloader and the application are loaded to the flash, I can press either SW1 or SW2 on the LaunchPad and I can see either D1 or D2 LED blink. I DO NOT see any issue where jumping from the bootloader to the application will create any faults. 

Why do you try it and then compare with your setup? I asked you questions and you never answered me. I asked you if you see a valid bootloader at 0x0. I also asked you if you add  m3Hwi.resetVectorAddress = 0x4000 to the .cfg file and you never answered me. 

Hi Charles,

Sorry to missing out on answering your questions

Yes,there is a valid bootloader at 0x0 and added m3Hwi.resetVectorAddress = 0x4000 to the .cfg file in tirtos_builds_MSP_EXP432E401Y_release_ccs

Charles Tsai said:

What is this file? Why do you need to change it?

It is linker.cmd file in tirtos_builds_MSP_EXP432E401Y_release_ccs and I have not made any modification to it.

Charles Tsai said:

See below steps I do and I'm able to run an RTOS application that is linked to 0x4000. 

Tried the above-mentioned steps. It works when done via UniFlash, but when I perform the USB firmware upgrade using BSL Scripter, it gets stuck in the HardFault handler.

Additionally, while checking the fault status registers, I observed a BusFault—which might have triggered the HardFault handler. And both the BusFault on stacking for exception entry and the imprecise data bus error bits were set."

Can you pls help us in achieving firmware upgrade using BSL scriptior. Please let me know if any details from my side is required

Akash S said:

Yes,there is a valid bootloader at 0x0 and added m3Hwi.resetVectorAddress = 0x4000 to the .cfg file in tirtos_builds_MSP_EXP432E401Y_release_ccs

Ok. The bootloader is there at 0x0. 

Akash S said:

Tried the above-mentioned steps. It works when done via UniFlash, but when I perform the USB firmware upgrade using BSL Scripter, it gets stuck in the HardFault handler.

I think there may be an issue that I need my CCS toolchain team for assistance. Below is what I tried. 

1. Use the BSL scripter to first load the usb bootloader. 

2. Once the usb bootloader is running, use the BSL scripter to load the buttonled_MSP_EXP432E401Y_tirtos_ccs.txt file. it loads fine but the LED does not blink. 

3. Repeat step 1 again. 

4. I generate the binary file for buttonled_MSP_EXP432E401Y_tirtos_ccs as in buttonled_MSP_EXP432E401Y_tirtos_ccs.bin. You can insert the below line to try out yourself. The post-build command is:

"${CCE_INSTALL_ROOT}/utils/tiobj2bin/tiobj2bin" "${BuildArtifactFileName}" "${BuildArtifactFileBaseName}.bin" "${CG_TOOL_ROOT}/bin/armofd" "${CG_TOOL_ROOT}/bin/armhex" "${CCE_INSTALL_ROOT}/utils/tiobj2bin/mkhex4bin"

5. Instead of using BSL_Scripter.exe, I use another tool that takes the bin file for USB DFU. The tool I use is called LM Flash Programmer. You can find this tool at https://www.ti.com/tool/LMFLASHPROGRAMMER

6. After the usb bootloader is running, it should find Device Firmware Update. Make sure you don't select a different DFU devices so you don't accidently upgrade the wrong DFU device. 

7. Provide the .bin file and set the address to 0x4000 and then hit the Program button. Once it finishes, I can see the LED blinks when I press the SW1/SW2 button on the LaunchPad.

Hi Charles,

Thanks for your response.

We tried to use LM flash programmer and we could load the program successfully.

However we would require the BSL scriptor (will build a custom application to execute the script) as our product will be updated at the field. We will not be able to train the end user to use LM flash programmer and we fear if we changes some settings while doing it. One more reason is we don't want to reveal our hardware details so are planning to give our own executable.

Please help us with the BSL scriptor, Charles

Akash S said:

However we would require the BSL scriptor (will build a custom application to execute the script) as our product will be updated at the field. We will not be able to train the end user to use LM flash programmer and we fear if we changes some settings while doing it. One more reason is we don't want to reveal our hardware details so are planning to give our own executable.

If this is the case, I will suggest you use the dfuprog.exe which is a command line tool. You can find this tool in C:\ti\TivaWare_C_Series-2.2.0.295\tools\bin\dfuprog.exe. You can download TivaWare from https://www.ti.com/tool/SW-TM4C. The source code for dfuprog.exe is located at C:\ti\TivaWare_C_Series-2.2.0.295\tools\dfuprog. 

When I generate the application .TXT file using CCS and then l load it using the USB DFU bootloader, it will load successfully but does not execute. When I compare the memory content that is loaded by USB bootloader against how it is loaded using Uniflash for a .out file, I see very subtle differences. A few locations are different. I don't know if this if CCS issue in terms of .txt generation or BSL_Scripter. Resolving the toolchain issue will take considerable amount of time. This is why I suggest you use the dfuprog.exe since you can customize however you want with the source code provided. 

Hi Charles,

We looked for dfuprog.exe file in the suggested location but couldn't find it.

Can you please guide us where to find it or is it renamed....

Hi,

  Can you download the SW-USB-win-2.2.0.295.msi? See below. Once downloaded, it will be in C:\Program Files (x86)\Texas Instruments\Tiva\usb_examples.

I'm also attaching the dfuprog.exe executable here. You can find the source code in C:\ti\TivaWare_C_Series-2.2.0.295\tools\dfuprog

https://e2e.ti.com/cfs-file/__key/communityserver-discussions-components-files/908/dfuprog.exe