MSPM0G3507: Bootloader Firmware Update issue

Hi Vinay,

Which GUI are you referring to? 

We have the following Documentation for performing firmware updates: MSPM0 Bootloader User's Guide (Rev. A)

We also have many software examples with our MCU receiving updates: Bootloader (BSL)

Best Regards,
Brian

Hi Brian Lee,

Thank you for your reply.

Now we are able to update Firmware of MSPM0G3507 Using BSL from UART using a external processor.

But the problem is we are not able to update the firmware we have built for MSPM0G3507. The Binaries provided in Bootloader Directory are working fine.

LFU_App1_tima_toggle_PB27_LP_MSPM0G3507_ticlang and LFU_App2_tima_toggle_PB22_LP_MSPM0G3507_ticlang.

We have changed the Linker script of the application same as LFU_App1_tima_toggle_PB27_LP_MSPM0G3507_ticlang's Linker Script. 

The binary size provided in bootloader is 3kb and the custom application what we have developed is of size 15kb. 

Will it cause issue. We are able to flash custom binary using Python Script provided in bootloader. But the application is not booting after updating.

Please let me know where we are lagging.

Thanks and regards,

Vinay

Hi Vinay,

If the flash length defined in the linker of the example (3 KB) is smaller than your custom application, attempted writes will spill into the adjacent memory section and result in an "illegal address" error. Once the bootloader jumps to the application, since it is incomplete, the CPU will lock up. To fix this, increase the LENGTH of the FLASH region in your linker script to accommodate your 15 KB application.

There is also a known issue in some of our example linker files where SRAM is defined as starting at 0x20000000 instead of
0x20200000. If the SRAM base address is wrong, data and stack will be placed at an invalid address, which will also prevent the
application from booting. Can you confirm SRAM is defined as 0x20200000 in all linker scripts - BSL and application?

Best Regards,
Brian

Hi Brian Lee,

The flash range of given example starts from 0x4000 and the length is 0xe000. And our custom application flash range starts from 0x4000 and the length is 0x46000. And SRAM in linker of example starts from 0z20201500 and length is 0x6b00. And we have not changed start address of SRAM in our custom application, but we have changed the length of it to 0x21700.

But still we are not able to boot the application once it updates from BSL.

Thanks and regards,

Vinay

Hi Vinay,

Both lengths exceed the physical memory of the device. Flash can be extended up to 0x1C000 (the remaining 112 KB after the 16 KB BSL at 0x4000) — 0x46000 is invalid. The SRAM length must be no larger than 0x6B00 from origin 0x20201500, as the device has only 32 KB total.

The SRAM length is the cause of your boot failure. With 0x21700, the linker places the initial stack pointer at 0x20223200 — well outside physical SRAM. The CPU loads that address into SP on reset, faults on the first stack operation, and never reaches main.

Best Regards,
Brian

Hi Brian Lee,

We have changed the linker file of custom application as per your input. Flash starting address is 0x4000 and length is 0x1C000 and SRAM address is 0x20201500 and length is 0x6E00. Still we are facing the same issue. Please we need your help.

Thanks and regards, 

Vinay

Hi Vinay,

Are you able to hold an active debug session after the bootloader attempts to jump to your target application?

If so, can you check the xPSR and share the exception value:

The following table can be used to decode it:

If it's an NMI (0x2), please also check the SYSCTL NMIIIDX register and compare with the included table:

If the above is not the case, are you able to recreate the issue on firmware you would be able to share with me so I can debug on my side?

Best Regards,
Brian

Hi Brian Lee,

I tried debugging bootloader application and when I update custom application using BSL python script 

followed below steps:

1. Started bootloader application.

2. Placed breakpoint @switch (app_area_flag) in void CMD_API_startApplication(void) api.

3. Ran python script for BSL Firmware Update.

4. Added GPR to Watch expressions.

5. Updated Custom application firmware using BSL Python script.
6. Update successful returned in Script.

7. Breakpoint got hit.

8. Reading xPSR Register.

added screenshots for your reference.

Thanks and regards,
Vinay

Hi Brian Lee,

Adding some note:

We observed small applications like blink led or take any small sized applications are working absolutely fine. There is no issue at all.

Hi Brian Lee,

waiting for your inpur. Please guide us with the solutions

Hi Vinay,

Looking back over the thread, I see that you modified the SRAM length to 0x6E00. 0x6E00 places the initial stack pointer at 0x20208100, which is 256 bytes beyond physical SRAM. Change it to 0x6B00 exactly. 

To catch the fault in the debugger, implement a HardFault_Handler in your custom application, then set a breakpoint inside it. The screenshots show the xPSR captured while still inside the BSL before the application jump, which will always show a clean state.

Best Regards,
Brian

Hi Brian Lee,

We have changed the linker script and generated the application. But we observed that .vtable segment is not getting created in the .map file.

will this create any issue in jumping to the application?

Thanks and Regards,

Vinay

Hi Brain Lee,

Sharing you the bootloader and Custom application with this response. Kindly please let us know the issue we are facing.

Thanks and regards,

Vinay

App.rarLFU_Bootloader_LP_MSPM0G3507_freertos_ticlang.rar