MSPM0-SDK: Connection to MSPM0 core failed

Nandini VK

Part Number: MSPM0-SDK
Other Parts Discussed in Thread: LP-MSPM0G3507, MSPM0G3507

I am using the LP-MSPM0G3507 LaunchPad and am currently working on a bootloader implementation for this microcontroller.

I want to use CAN as the BSL communication interface, so I imported the TI SDK example project bsl_can_flash_interface without making any changes to the source code.

In the CCS flash programming settings, I enabled:

Erase MAIN memory & Erase NONMAIN memory

Before programming the CAN plug-in, I performed a Factory Reset.

The Factory Reset completed successfully and CCS displayed the following message:

CS_DAP_0: Command Sent
CS_DAP_0: Start hardware Reset using NRST
CS_DAP_0: Initiating BOOTRST Board Reset
CS_DAP_0: Reset line asserted
CS_DAP_0: Reset line de-asserted
CS_DAP_0: Board Reset Complete
CS_DAP_0: Reset done
CS_DAP_0: SEC_AP Disconnect
CS_DAP_0: SEC_AP Reconnect
CS_DAP_0: Command execution completed.

Factory Reset executed.

Please terminate debug session, power-cycle and restart debug session.

I then terminated the debug session, power-cycled the board, and tried to flash the bsl_can_flash_interface project.

However, while programming the CAN plug-in, I received the following errors:

Error: (Error -1001 @ 0x0)
Requested operation is not supported on this device.

Trouble Halting Target CPU:
(Error -2064 @ 0x0)
Unable to read device status.

Error:
Connection to MSPM0 core failed.

Possible root causes:
1) Debug access within NONMAIN was disabled or enabled with password.
2) Peripheral mis-configuration (e.g. improper watchdog or clock).

I initially suspected that the device might have become locked due to NONMAIN configuration.

To verify this, I programmed a simple LED-blinking application onto the same MSPM0G3507.

The LED-blinking application was programmed successfully, which indicates that the device is not locked and that the XDS110/debug connection is working correctly.

Therefore, the current situation is:

Factory Reset                         → Successful
LED-blinking application programming  → Successful
bsl_can_flash_interface programming   → Failed

Since the normal LED application can be programmed successfully, the issue appears to be specific to programming the bsl_can_flash_interface project, rather than the MSPM0G3507 being locked or the XDS110 connection being completely unavailable.

I would like to understand why the bsl_can_flash_interface example fails to program even after performing a Factory Reset and enabling both MAIN and NONMAIN erase.

19 days ago

0 Nandini VK 19 days ago

Prodigy 20 points

I forgot to post the screenshot of syscfg file.

0 Sal Ye 18 days ago in reply to Nandini VK

TI__Mastermind 32175 points

Hi Nandini,

For the default setting, the bsl_can_flash_interface project can be only programmed one time as it locked the NONMAIN and partial main region (where the can bsl interface located) in NVM configuration.

After it is programmed, device can not run its functionality as it is a plug-in interface, instead of a whole debug-able project. You can read the flash region after program to verify whether it is programmed successfully.

To verify whether the plug in interface functionality, you can use another EVM which download the bsl_host_can to send CAN frame to program this board. The example is loacted in:

https://dev.ti.com/tirex/explore/node?isTheia=false&node=A__AJBMnQqT6cT9mnDVJPL89w__MSPM0-SDK__a3PaaoK__LATEST&placeholder=true

B.R.

Sal

0 Nandini VK 18 days ago in reply to Sal Ye

Prodigy 20 points

Hi Sal,

Thanks for the reply.

Sal Ye said:
You can read the flash region after program to verify whether it is programmed successfull

How can I verify the value that will be stored in the Flash memory area?

Sal Ye said:
You can read the flash region after program to verify whether it is programmed successfull

I currently have only one EVM, so I’m unable to verify the plug-in interface functionality using another setup.

Is there any GUI or Python script available that can be used to configure the PC as the host and test the plug-in interface functionality?

If not, is it possible to generate a Python script for this purpose?

0 Sal Ye 18 days ago in reply to Nandini VK

TI__Mastermind 32175 points

Hi Nandini,

Nandini VK said:
How can I verify the value that will be stored in the Flash memory area?

Connect device and read memory to see if the flash region of flash plug-in interface has the data.

Nandini VK said:
Is there any GUI or Python script available that can be used to configure the PC as the host and test the plug-in interface functionality?

No, the major things is that the PC can not directly output CAN frame to CAN bus, so users need a USB-CAN bridge to work.

The another EVM board just works as a CAN bridge, and we provide the CAN bridge protocol in SDK.

Nandini VK said:
If not, is it possible to generate a Python script for this purpose?

This is doable if you have a CAN analyzer, and you need to create a specific script of the analyzer to simulate the protocol we defined in SDK example.

B.R.

Sal

0 Nandini VK 17 days ago in reply to Sal Ye

Prodigy 20 points

Hi Sal,

Thanks for your response.

Sal Ye said:
This is doable if you have a CAN analyzer, and you need to create a specific script of the analyzer to simulate the protocol we defined in SDK example.

Through PCAN also it is possibile, right?

Sal Ye said:
The another EVM board just works as a CAN bridge, and we provide the CAN bridge protocol in SDK.

Ok, I'll check.

Thanks,

Nandini.

0 Sal Ye 17 days ago in reply to Nandini VK

TI__Mastermind 32175 points

Hi Nandini,

Nandini VK said:
Through PCAN also it is possibile, right?

Yes.

Nandini VK said:
The another EVM board just works as a CAN bridge, and we provide the CAN bridge protocol in SDK.

Ok, I'll check.

The flow is that users force the EVM enter BSL mode by keep pressing S1 button (PA18, BSL invoke pin) and reset device (S3 button).

Then use scripts to send the specific CAN frame (according to SDK example) to establish the CAN BSL connection.

Then follow the CAN BSL protocol (according to SDK example) to send the firmware which is required to loaded to MCU.

B.R.

Sal

0 Nandini VK 11 days ago in reply to Sal Ye

Prodigy 20 points

Hi Sal,

The above image from bsl_software_invoke_app_demo_can project.

What is FLASH2 area here?

where we have to give application start address.
Does we need to give application start address in the .cmd file?
I've a doubt, Bootloader will store in Non-Main, so the application will start from 0x00000000?
could you please clarify this one.

Thanks,

Nandini.

0 Nandini VK 1 day ago in reply to Nandini VK

Prodigy 20 points

Hi Sal Ye ,

The following is the original content from the bsl_software_invoke_app_demo_can project's .cmd file:

-uinterruptVectors

--stack_size=512

MEMORY

{

FLASH (RX) : origin = 0x00000000, length = 0x00001000

FLASH2 (RX) : origin = 0x00003800, length = 0x0001C800

SRAM (RWX) : origin = 0x20200000, length = 0x00008000

BCR_CONFIG (R) : origin = 0x41C00000, length = 0x00000080

BSL_CONFIG (R) : origin = 0x41C00100, length = 0x00000080

}

SECTIONS

{

.intvecs: > 0x00000000

.text : palign(8) {} > FLASH | FLASH2

.const : palign(8) {} >> FLASH | FLASH2

.cinit : palign(8) {} > FLASH | FLASH2

.pinit : palign(8) {} >> FLASH | FLASH2

.rodata : palign(8) {} > FLASH | FLASH2

.ARM.exidx : palign(8) {} >> FLASH | FLASH2

.init_array : palign(8) {} >> FLASH | FLASH2

.binit : palign(8) {} > FLASH | FLASH2

.TI.ramfunc : load = FLASH, palign(8), run=SRAM, table(BINIT)

.vtable : > SRAM

.args : > SRAM

.data : > SRAM

.bss : > SRAM

.sysmem : > SRAM

.stack : > SRAM (HIGH)

.BCRConfig : {} > BCR_CONFIG

.BSLConfig : {} > BSL_CONFIG

}

I changed the application Flash starting address to 0x00003800 and modified the .cmd file accordingly:

-uinterruptVectors

--stack_size=512

MEMORY

{

FLASH2 (RX) : origin = 0x00003800, length = 0x0001C800

SRAM (RWX) : origin = 0x20200000, length = 0x00008000

BCR_CONFIG (R) : origin = 0x41C00000, length = 0x00000080

BSL_CONFIG (R) : origin = 0x41C00100, length = 0x00000080

}

SECTIONS

{

.intvecs: > FLASH2

.text : palign(8) {} > FLASH2

.const : palign(8) {} > FLASH2

.cinit : palign(8) {} > FLASH2

.pinit : palign(8) {} > FLASH2

.rodata : palign(8) {} > FLASH2

.ARM.exidx : palign(8) {} > FLASH2

.init_array : palign(8) {} > FLASH2

.binit : palign(8) {} > FLASH2

.TI.ramfunc : load = FLASH2, palign(8), run=SRAM, table(BINIT)

.vtable : > SRAM

.args : > SRAM

.data : > SRAM

.bss : > SRAM

.sysmem : > SRAM

.stack : > SRAM (HIGH)

.BCRConfig : {} > BCR_CONFIG

.BSLConfig : {} > BSL_CONFIG

}

After building the project and attempting to flash it, I received the following error:

File Loader: Memory write failed: Flash loader exited with flash error.
GEL: File: C:\Users\workspace_ccstheia\bsl_software_invoke_app_demo_can\Debug\bsl_software_invoke_app_demo_can.out: Load failed.

Error: (Error -1001 @ 0x0) Requested operation is not supported on this device.
(Emulation package 20.5.0.3902)

Trouble Halting Target CPU:
(Error -2064 @ 0x0) Unable to read device status.
Reset the device, and retry the operation. If the error persists, confirm the configuration, power-cycle the board, and/or try more reliable JTAG settings (e.g. lower TCLK).
(Emulation package 20.5.0.3902)

My requirement is to start the application from 0x00003800.

Could you please let me know how I can achieve this correctly?
I have been waiting for your response for quite some time. Could you please provide an update on this issue?

Also, I added a function to transmit a CAN message in this project. The project builds successfully without any errors, but I am unable to flash the generated .out file. I get the same flashing error even when using the original .cmd file.

Error -1001 @ 0x0: Requested operation is not supported on this device.

It is followed by:

Error -2064 @ 0x0: Unable to read device status.

Could you please help me understand the cause of this issue as well?

Regards,
Nandini

Arm-based microcontrollers

Arm-based microcontrollers forum

MSPM0-SDK: Connection to MSPM0 core failed