MSPM0G3507: flashing problem

Hi Crane,
You shouldn't' erase non-main since it can lock you out of the device. I recommend trying a DSSM Mass Erase.
Best Regards,
Diego Abad

Hi Diego,

Ok. Then how to do DSSM Mass Erase?

Both DSSM Mass Erase and DSSM Factor Reset can't be selected in the below popup window.

Thanks!

Crane

Hi Crane,
I would recommend downloading CCS 18.1 and using the online guide I'll link here to do so. 

e2e.ti.com/.../Factory_5F00_reset_5F00_v2.pdf

Best Regards,

Diego Abad

I installed CCS12.8.1. Here is the pop-up menu after right-clicking .ccxml file.

There is no option 'Launch Selected Configuration" as in the guideline.

And the CCS of newer version will be V20.0.0 and there is no 18.1 version.

Thanks!

Crane

Hi Crane,
Sorry about that, I misclicked the TI Thinks Resolved button. You can do this by exporting the project and import it back CCS 12.8.1. However, the Mass erase can work in any project.

Hi Crane,
You need to click on the view tab and then click on Target Configuration. Then you should see the option Launch Selected Configuration. You are correct, the new version of CCS is the 20.0.1. I meant to say to download the CCS 12.8.1 version (Eclipse based IDE) and follow the attached document.

Best Regards,

Diego Abad

Hi Diego,

It fails at the step to attempting CS_DAP connection. Here is the message:

CS_DAP_0: GEL Output: Initiating Device Factory Reset
CS_DAP_0: GEL Output: Attempting CS_DAP connection
CS_DAP_0: Error connecting to the target:  DAP Connection Error. This could be caused by the device having gone to low power mode. Try forcing an external reset.If the error persists, try forcing BSL, a Mass erase or a Factory Reset. Check device FAQs for more information. 
CS_DAP_0: GEL Output: Initiating BOOTRST Board Reset
CS_DAP_0: GEL Output: Reset line asserted 
CS_DAP_0: GEL Output: Reset line asserted 
CS_DAP_0: GEL: Error while executing GEL_DAPInit_externalReset(): Timer id 1 is already configured to call "GEL_DAPInit_resetDeassert()" and must first be canceled
	 at GEL_SetTimer('GEL'::gDAPBoardResetLen, 1, "GEL_DAPInit_resetDeassert()") [mspm0_cs_dap_init.gel:180]
	 at GEL_DAPInit_externalReset()
CS_DAP_0: GEL Output: Reset line de-asserted 
CS_DAP_0: GEL Output: Board Reset Complete
CS_DAP_0: GEL Output: Reset done
CS_DAP_0: Error connecting to the target:  DAP Connection Error. This could be caused by the device having gone to low power mode. Try forcing an external reset.If the error persists, try forcing BSL, a Mass erase or a Factory Reset. Check device FAQs for more information. 
CS_DAP_0: GEL: Error while executing GEL_DAPInit_remoteFactoryReset(1): Connect failed
	 at GEL_Connect() [mspm0_cs_dap_init.gel:359]
	 at GEL_DAPInit_remoteSECAPCommand(0x020AU, autoReset) [mspm0_cs_dap_init.gel:323]
	 at GEL_DAPInit_remoteFactoryReset(1)

What does it mean? What might happen to do mass erase? 

In terms of export/import a project. There is no option of "export" in CCS Theia as in CCS. 

There is a post which says to zip the project in CCS Theia and then import to CCS. I tried and CCS can't import the archive which is from zipping the original project from CCS Theia. If just unzipping the project, the result is the same as simply copying the original project.

Thanks!

Crane 

Hi Crane,
That means that the Mass Erase failed (I think most likely because it couldn't connect to the board.) You don't need to export it to the version I mentioned since CCS Theia or CCS 20.0.1 should be good. Could you send me a picture of your jumper configuration?
Best Regards,
Diego Abad

Hi Diego,

Here is the picture:

Yes I understand that. The purpose for me to move the project from CCS Theia to CCS is that I want to use CCS instead of CCS Theia if there won't be too much work to move as I feel CCS is more convenient:-)  I just know that CCS new version can handle MSPM0 project.

Thanks!

Crane

Hi Crane,
Thew new version of CCS is using the Theia IDE, so it should run relatively the same as the CCS Theia version you are using. You should be able to just open the project in the newest CCS as you would do in your current version of CCS. I'll ask around my team to see if there's anything I can recommend for your flash problem. 

Best Regards,

Diego Abad

Hi Crane,
Sorry for the late response. I noticed you have a cable connected to the fiducial mark near the OPA2365 (green cable.) Is there a reason why you have it connected there? Also, here's a tool that may help you out. Let me know if it works for you: https://dev.ti.com/gallery/view/TIMSPGC/MSPM0_Factory_Reset_Tool/ver/1.0.2/

Best Regards,

Diego Abad

Hi Diego,

Thank you for your reply.

The green cable is the ground when connecting this board to another board through UART.

I installed everything and then attach and then execute, but nothing displays on the output console.

After clicking the grey icon, there is line displaying at the bottom saying "Error: failed to connect: There is no active configuration to connect with.

Any idea?

Thanks!

Crane

Hi Crane,
The last thing I can think of is to try a Factory Reset, but I think you already tried that. One option is to do the factory reset through UNIFLASH, but you'll need a JTAG programmer. Maybe the green cable could be affecting the board's ground, but I'm not 100% sure about it. Due to that, the launchpad seems to have been locked down. Can you describe what projects you ran before the device showed you that error?
Best Regards,
Diego Abad

Hi Diego, what you mean "try a Factory Reset"? Is Factory Reset Auto of "Factory Reset"?

I do have JTAG programmer and tried UNIFLASH. Here is the result:

Is it possible that the debug interface is broken?

When I do the factory reset, the grand cable isn't connect to anything.

The project I was trying was to connect this board to another board using UART on Pin PA9 and PA8. This board is powered by external power supply and the USB only worked as an UART interface. Another board is powered by USB working as an UART interface as well. Both boards uses the UART on USB as a console and UART on PA8/PA9 as the communication channel between two boards. Then suddenly I realized that the board that is supplied by the external power couldn't be flashed any more. The external power supply is a DC power supply, configured at 1A current limit at least. Later two more boards got the same results. But it doesn't always cause this result as later I got two boards working fine connected this way.

Thanks!

Crane

Hi Crane,
Since the other two boards you mentioned are working, then it is very likely that the board that isn't able to connect to anything is either locked or dead. From what I can see in the datasheet, the G3507 can't handle a current higher than 100mA. Thus, it seems the board is dead. 

Best Regards,

Diego Abad

Hi Diego,

To clarify one thing, when I said "... later I got two boards working fine connected this way.", I mean the two boards that are connected through UART communication on PA9/PA8. It means this way to connect the two boards isn't the cause of the totally three boards having gotten this issue I am trying to solve.

So, you mean the broad is broken so that the error I am getting when flashing it can't be fixed through doing "factory reset auto", right?

One thing I observe is that the board is still working, but just can't be flashed with the new code. This is why I am afraid that it is the debug interface on the board that is broken. Is there any way or any error information to verify this assumption?

Thanks!

Crane

Hi Crane,
You could prove some data lines in the board (XDS110 or JTAG) and see if any data is going through. However, if the board is still working with the previous project that was run into it, then you're probably correct in assuming that the "communication to the board" part is broken. Sadly, this can't be fixed through a factory reset because it can't connect to the board.
Best Regards,
Diego Abad

Hi Diego,

It looks the signals on SWDIO and SWCLK are the same on the working board and non-working board. But the results are different.

But "force reset" is still able to reset the board while the program is running. This could indicate the communication still exist under certain conditions and hardware on SWD pins are working fine.

Since there is the statement saying "This could be caused by the device having gone to low power mode". Probably the SWD is not responding when the MCU is in low-power mode. Is there anyway to verify this?

CS_DAP_0: Error connecting to the target:  DAP Connection Error. This could be caused by the device having gone to low power mode. Try forcing an external reset.If the error persists, try forcing BSL, a Mass erase or a Factory Reset. Check device FAQs for more information. 
CS_DAP_0: GEL: Error while executing GEL_DAPInit_remoteFactoryReset(1): Connect failed
	 at GEL_Connect() [mspm0_cs_dap_init.gel:359]
	 at GEL_DAPInit_remoteSECAPCommand(0x020AU, autoReset) [mspm0_cs_dap_init.gel:323]
	 at GEL_DAPInit_remoteFactoryReset(1)

I am looking for the root cause of this issue to prevent this from happening again as we have already gotten three boards not working in a row and we don't know what caused this yet. I am wondering what kind of actions potentially cause the MCU entering low-power mode as I never intentionally did this. If we could make this happen, then we can see if the MCU in low-power mode behaves the same as what we are seeing right now.

Thanks!

Crane

Hi Crane,
I think the cause could be the 1A of the current board being fed. I would recommend lowering it to the levels you see in the datasheet.  When you mention "force reset," do you mean the original reset you tried, "S1 Pressed down and then S3 Pressed down"? If that's the case, then that part of the launchpad may not be broken (what should happen is that the board's main flash memory is erased, which means the launchpad looks inactive). I don't think there is a low-power mode that could lock the device, but feel free to try that out. 
Best Regards,
Diego Abad

Hi Diego,

1A limit I mentioned before is the current limit set for the power supply, not the current feeding to the board. It means the power supply would not supply the the power if the board draws over-1A current.

The "force reset" mentioned in last post is the button as in below picture after "factory reset auto" failed.

Thanks!

Crane

Hi Crane,

Most of the time that error indicates that the Launchpad can't communicate with the IDE. Sometimes this error will be more than just the device falling into a deep sleep mode (similar to what you are seeing right now.) Would you mind sharing the project you are using? I want to run it in one of my boards and see if it could be a problem with the program. 

Best Regards,

Diego Abad

Hi Diego,

Yes, this is what the error message says. I will share the project with you.

Thanks!

Crane

Hi Crane,
I ran your project in an LP-MSPM0G3507. I successfully debugged, flashed in CCS 20.0.2, and reset the launchpad with the "S1 + S3" reset. Since the program works on this launchpad, I think there could be something wrong with your current hardware setup that might be making the launchpad unable to communicate with CCS. 
Best Regards,
Diego Abad

Hi Diego,

Yes, it is because something is wrong with the board, not the program. That's what I would like to find out and its potential cause.

You mentioned about deep sleep mode. Is it possible the problem with the board?

Thanks!

Crane

Hi Crane,
Since the board worked before it was placed in your set up, I don't think the problem could be with the board. The low power modes we have shouldn't lock the board to the point of not being able to communicate with the IDE.

Best Regards,

Diego Abad

Hi Diego,

If the problem is not with the board and you tested the program is working, then what else could potentially be the problems that causes no communication between the board and the IDE?

The board did work before it was placed in my setup and it worked after being placed in my setup. But from some moment it didn't work any more. That's what we are discussing from the beginning, right?

Thanks!

Crane

Hi Crane,
Since the board stopped communicating at some time in your setup, there must have been something that, at some point, could have broken its capability to talk with the IDE. Is there any specific event you can think of that may have led to the breaking of the device? Things like how much time passes after the device is in the setup and then malfunctions, at which point of the project the device stops communicating with the IDE, measuring current input to the board.
Best Regards,
Diego Abad

Hi Diego,

It happens when connecting two boards through UART communication. But I don't remember exactly any moment or any event as it suddenly happened and I didn't prepare to measure how much time passed, the current to the board, etc.

Right now, the program in the board is still running and it just can't be flashed with new program and can't be connected with the debugger. And the error comes up as posted before when doing "factory reset auto".

There are two potential causes: 1) the debug pins are broken; 2) the device is in low power mode as mentioned in the error message. 

The questions now are: 1) are there any other potential causes? 2) Is there a way to verify if the device is indeed in low power mode so that it doesn't respond to the debugger/IDE. If it is in low power mode, it is not supposed to run, right? 

We already discussed much. If there is no new input to these questions, that's fine for now. 

Thank you for your support!

Crane

Hi Crane,
The other way to test for low power mode will be to use a multimeter and measure the current going through the launchpad (connecting one pin to any ground pin and the other to any 3.3V pin.) For accurate results, you'll need to remove all jumpers from the board and power the board externally. After you get the current readings, compare them to the current estimates given in the 7.5 Supply Current Characteristics in the device Datasheet. However, the device being in low power mode shouldn't make the debug pins not work. Aside from that, there aren't other things I can think of that could make the board break. 
Best Regards,
Diego Abad

Hi Diego,

I will measure the current later.

We just got a new board that can't be flashed with this error. This happened when we disconnected and reconnected the power of a sensor board which is connected to this board.

The error message is as the following when flashing the new program:

"CORTEX_M0P: GEL Output: Memory Map Initialization Complete
CORTEX_M0P: File Loader: Memory write failed: Timed out waiting for target to halt
CORTEX_M0P: GEL: File: C:\work_ccs1281\prj_mspm0_lcd\Debug\prj_mspm0_lcd.out: Load failed.
CORTEX_M0P: Failed CPU Subsystem Reset: (Error -2063 @ 0x0) Unable to reset device. Power-cycle the board. If error persists, confirm configuration and/or try more reliable JTAG settings (e.g. lower TCLK). (Emulation package 20.0.0.3178)"

When doing "test connection:, the information is as the following:

[Start: Texas Instruments XDS2xx USB Debug Probe_0]

Execute the command:

%ccs_base%/common/uscif/dbgjtag -f %boarddatafile% -rv -o -S integrity

[Result]


-----[Print the board config pathname(s)]------------------------------------

C:\Users\CRANES~1\AppData\Local\TEXASI~1\
    CCS\ccs1281\0\0\BrdDat\testBoard.dat

-----[Print the reset-command software log-file]-----------------------------

This utility has selected a 560/2xx-class product.
This utility will load the program 'xds2xxu.out'.
The library build date was 'Sep 26 2024'.
The library build time was '14:57:19'.
The library package version is '20.0.0.3178'.
The library component version is '35.35.0.0'.
The controller does not use a programmable FPGA.
The controller has a version number of '13' (0x0000000d).
The controller has an insertion length of '0' (0x00000000).
This utility will attempt to reset the controller to enter SWD mode.

-----[Print the reset-command hardware log-file]-----------------------------

This emulator does not create a reset log-file.

-----[Perform the SWD Mode Integrity test]-----------------------------------

This test will read the IDCODE register 1 time.

The IDCODE register value is 0x6ba02477.

Any idea on this error and how to fix it?

Thanks!

Crane

Hi Diego,

The current is always around 100mA. It doesn't affect the current no matter how many jumps are removed. It is much larger than IDDrun in the spec. Not sure why it is so high. If so, it shouldn't be in low power mode.

Thanks!

Crane

Hi Crane,
I haven't encountered this error before. However, since you communicate with the device, you should try to do an MSPM0_Mailbox_FactoryReset_Auto, which should reset the launchpad to factory settings. As for the high current consumption, be aware that that current consumption is the maximum the device allows. Having this current level for a prolonged period could cause weird behaviors in the device.
Best Regards,
Diego Abad

Hi Diego,

For the newly-damaged board, "factory reset auto" is working fine (for previously-damaged board, even "factory reset auto" is not working), but still have error when flashing the program as described in last post after completing the "factory reset auto".

For the 100ma current, it is not consumed by the project, it is a bare launchpad board with nothing connected, and even all jumpers are removed. The purpose is to check if it is in low power mode as you suggested.

Thanks!

Crane

Hi Crane,
If the launchpad is reaching 100mA on its own, it is even more concerning since that is the device's maximum input current, AKA running a project on it, which will most likely increase it to levels higher than 100mA. Can you try removing the board from your setup and feeding it the standard micro-USB power from the computer? Do you see the same current consumption? 
As for the error you are seeing, could you try to flash the board through CCS using only a micro-USB cable without being connected to your setup?
Best Regards,
Diego Abad

Hi Diego,

I followed the way you suggested to measure the current in one of previous posts to verify if it is in low power mode. Is it what you mean?

The other way to test for low power mode will be to use a multimeter and measure the current going through the launchpad (connecting one pin to any ground pin and the other to any 3.3V pin.) For accurate results, you'll need to remove all jumpers from the board and power the board externally.

For the newly-damaged board, it is fixed by conducting "factory reset auto" multiple times. 

Thanks!

Crane

Hi Crane,
Glad to hear that doing the factory reset worked. The launchpad should be powered by an external power supply (3.3V and current levels withing the range) through any 3.3V and ground pins (I personally connect them to the 3.3V and ground in the pins on the XDS110, but this can be to any pin labeled in the launchpad,) and the multimeter should be connected to the same or another 3.3V and ground pins. If the current levels you measure are 100mA, then I would recommend to lower it. You can also measure the power consumption through the Energytrace tool through CCS . 

Best Regards,

Diego Abad 

Hi Diego,

I am a little confused. Isn't the purpose of measuring the current this way to judge if the MCU is in low-power mode? What do you mean to lower it? Nothing is connected to this MCU when the current is measured this way.

Thanks!

Crane

Hi Crane,
This is just advice I'm recommending in regards of the current limits of the device.

Best Regards,

Diego Abad

Hi Diego,

Ok. Then what do you mean when saying the following in one of previous posts:

Diego Abad Sajamin said:

The other way to test for low power mode will be to use a multimeter and measure the current going through the launchpad (connecting one pin to any ground pin and the other to any 3.3V pin.) For accurate results, you'll need to remove all jumpers from the board and power the board externally. After you get the current readings, compare them to the current estimates given in the 7.5 Supply Current Characteristics in the device Datasheet.

So, it is not about verifying the low power mode?

Thanks!

Crane

Hi Crane,
This is a method that can be used to verify if a device in a low power mode since the current consumption is directly related to the power mode the device is in. What I'm trying to say it's that the device seems to be running as normal AKA in Power mode RUN0, and that the device has a higher current than I expected. Nevertheless, since it seems to stay at 100mA AKA the maximum, it is within the limits the datasheet mentions. 

Best Regards,

Diego Abad 

Hi Diego,

So, from the result of 100mA current consumption, the device is not running in low power mode, right?

Thanks!

Crane

Hi Crane,
Based on the readings, that is what I can assume. Normally, really lower power modes make the device go into the micro Amp range rather than the mili Amp range. 
Best Regards,
Diego Abas

Hi Diego,

Ok, got it. 

But actually there is no big difference in current from the space.

Here is the low power mode current:

It is in uA, but the value could be in mili Amps range. Not sure why it is like this.

Thanks!

Crane

Ok got it. Thanks Diego!

Crane