MSP-GANG: MSP-GANG for MSPM0L1306

Hi Brandon,

Thank you for the support.

Best regards,

Kenley

Hi Brandon,

My customer has tried to connect as you mentioned.

However, the result was error as shown below.

• Fail (error 23) remains even if "current" or "VCC settle Time" is changed 
• Fail (error 23) when the speed of the SWD is changed.
• When you change the target, it remains Fail (error 23)

Could you please share how to fix this ?

We found a forum for a similar case in a closed thread, but there was no result which could not be a reference.  
MSPM0L1305: MSP-GANG Programmer Error - Arm-based microcontrollers forum - Arm-based microcontrollers - TI E2E support forums

Thank you in advance.

Best regards,

Kenley

Hi Kenley,

The connections seem correct to me. 

Were they doing any development with the launchpad before? Can they try resetting the device into BSL mode and then programming it?

They can do this by holding down S1 (BSL Invoke/PA19)  and then pressing S3 (Reset). After pressing S3 they can release S1 and try to program the device. 

Best Regards,
Brandon Fisher

Hi Brandon,

Thank you for your support.

Yes, they were doing debug using the launchpad before. Any concern on that ?

About the BSL, why should they use BSL mode ? 
Because they will write using SWD not BSL in the future.

Thank you in advance.

Best regards,

Kenley 

Hi Kenley,

Kenley said:

Yes, they were doing debug using the launchpad before. Any concern on that ?

It is possible to have code running on the MSPM0 that interrupts or makes it difficult for the debug tools to connect.

This can be something like an out of spec value of MCLK, a watchdog reset loop, a bad reconfiguration of non-main, etc.

Kenley said:

Because they will write using SWD not BSL in the future.

They would not normally need to do this for devices, I'm only really suggesting it because this is a launchpad that was likely used for debug or development at some point. Invoking BSL mode (assuming BSL mode invocation is still enabled in non-main), prevents any bad application code from running on the device.

Best Regards,
Brandon Fisher

Hi Brandon,

Customer has tried to do as you guided but even if they operate S1 and S3, it seems to be SWD, not BSL.
They have shared the waveforms with MSP-Gang hope it would be a hint to fix this issue.
They have tried so many times. Please refer to the attached file.

Thank you in advance.

Best regards,

Kenley

Kenley,

Kenley said:

Customer has tried to do as you guided but even if they operate S1 and S3, it seems to be SWD, not BSL.

SWD will still work on a device in BSL mode if SWD is still enabled in nonmain.

Kenley said:

They have shared the waveforms with MSP-Gang hope it would be a hint to fix this issue.
They have tried so many times. Please refer to the attached file.

That NRST traffic doesn't look normal to me, but I will check internally to be sure.

In the meantime, can you also have them try a factory reset of the device? Here are the instructions from the SDK guide on how to do this in CCS: https://dev.ti.com/tirex/content/mspm0_sdk_1_30_00_03/docs/english/tools/ccs_ide_guide/doc_guide/doc_guide-srcs/ccs_ide_guide.html?highlight=reset#dssm-mass-erase-factory-reset-wait-for-debug-and-set-reset-mode

Best Regards,
Brandon Fisher

Hi Brandon,

Thank you.

Please let me know when you have checked it.

For the factory reset, should they select the following ?

• MSPM0_MailboxFactoryReset_Auto: A factory reset will be performed forcing reset using the XDS110 reset line.

or 

• MSPM0_MailboxFactoryReset_Manual: A factory reset will be performed asking the user to press the reset button.

Thank you and best regards,

Kenley

Hi Kenley, 

They can use either. Auto is slightly simpler. 

Best Regards,
Brandon Fisher

Hi Brandon,

They have tried the factory reset but it was not working.

However, they have tried the old "experimental silicon" version launchpad and it is working.

They are suspecting that the MSP-GANG might not support the latest silicon one.

Thank you in advance.

Best regards,

Kenley

Hi Kenley,

Kenley said:

They have tried the factory reset but it was not working.

Meaning the factory reset was successful but the silicon still did not program, or the factory reset was not successful?

Do they have another board they can try? Is the out of the box example project they are trying to program compiled for the new silicon or for the old silicon? 

I've programmed the released MSPM0L1306 silicon before, and after testing it again with the latest version of the MSP-GANG GUI it does appear to work on my end. With the same connections as recommended above. 

Best Regards,
Brandon Fisher

Hi Brandon,

The factory reset was successful, but the silicon still did not program.

Currently, they do not have another board to try.

Brandon Fisher94 said:

Is the out of the box example project they are trying to program compiled for the new silicon or for the old silicon?

Sorry, i don't get this. could you please elaborate ? they were trying to compile the same out of the box program for both.

Best regards,

Kenley

Hi Brandon,

Customer did as guided and the following is the error shown.

Even if they write with MSP-Gang after FactoryReset, it remains Fail and does not change.
The Fail message is “ERROR23:MCU Device initialization Failed”.

They did the same (FactoryReset) with the “Experimental silicon” MCU and they can write it.

Thanks and regards,

Kenley

Hi Kenley,

Kenley said:

Brandon Fisher94 said:

Is the out of the box example project they are trying to program compiled for the new silicon or for the old silicon?

Sorry, i don't get this. could you please elaborate ? they were trying to compile the same out of the box program for both.

Code made for the pre-production (Rev A) version of the silicon will not work with the current devices. I just want to be sure that the code is being compiled using the production version of the tools (the latest version of all tools, CCS, SDK & SysConfig will work here).

If you can ask what version of CCS and the MSPM0 SDK they are using with the pre-production, and what version they are using with the production silicon that could be helpful.

We should send them more launchpads as well. If they have been programming the production silicon with pre-production tools, then it is possible something on the production device has been configured incorrectly. If they are using the production tools to build/compile/factory reset then this isn't as much of a concern.

Best Regards,
Brandon Fisher

Hi Brandon,

Thank you for your support.

We are using the latest SDK(mspm0_sdk_1_30_00_03), latest MSP-GANG(released 1.03.08.00 (15 Aug 2023))  but still could not connect to the production MSPM0L1306 launchpad.

I have also tried to run the example projects of "out of box" before connecting it to msp-GANG but still it does not work.

I have contacted elprotronic regarding this.

It seems like they will update the software to handle the device low-power modes. 

I will wait for the update and try again.

Best regards,

Kenley

Thanks Kenley,

Understood, if the update does not solve your issue please feel free to post again.

Best Regards,
Brandon Fisher

Hi Brandon,

They have provided the beta version but the update does not solve my issue.

Best regards,

Kenley

Hi Kenley,

Okay. Is it the same issue/error message or has that changed at all with the new version?

If its the same, I'd refer back to my earlier comment then about trying another launchpad.

Its possible that something on this device specifically is giving issues. I have not been able to recreate the device initialization error except with the low power mode on the current MSP-GANG GUI.

Best Regards,
Brandon Fisher

Hi Brandon,

Yes, the same error 

I have tried using different launchpad, and succesfully wrote by GANG. 

It is odd that the current issue launchpad could be written by CCS but not GANG.

Best regards,

Kenley

Hi Kenley,

I agree. I'm not sure what in the MSP-GANG programming process would be different versus the XDS110 connection process that would create this kind of failure on one device and not another.

The launchpads are only really production tested with the onboard XDS110 since that is their most common use configuration, so its possible if such an issue existed on a device/board after assembly our production test would not catch it. However, if this is re-creatable on any other boards please let me know.

Best Regards,
Brandon Fisher

Thanks for confirming Kenley,

I'm not sure how a launchpad ended up with a Q marked device, but hopefully this will be handled by the Gang software in the future.

Best Regards,
Brandon Fisher