MSPM0G1507: The target indicates there is an error condition from a previous SWD request.

Hi Steffen,

Did you update the version of the SDK that your project is using as well, or did you just update the CCS version and import to the new CCS installation?

I want to be sure that the issue is with CCS Theia, and not with the SDK. You could also optionally try compiling the project in the old CCS where is was working, and in the new CCS where it is not working, then compare the output using something like beyondcompare. If you are using the same SDK, the source should stay the same, and the compiled output should remain the same.

Hi Dylan,

thanks for the quick reply.

I`ve also updated the SDK from 2.2.0.05 to 2.3.0.07 and sysconf from 1.21.1 to 1.22.0.

Compiler is still TI clang 4.0.1. LTS.

At the moment I´ve got no working device. I have to order new MSPM0G1507 -> which I already did.

I`ve also deactivated the auto linker file creation by sysconf in order to define my own linker file. I needed an extra section in flash for the eeprom emulation.

Best regards

Steffen

I see ok, thanks for the update. Please let me know when you have some new devices to try this experiment on.

So far I have not seen other complaints similar to this, so I do not suspect it is purely an issue with the new tools installations, but we can rule that out with further testing and by checking the tools with tests like the one above. 

I assume that your custom linker has not changed at all during this time either? I'd like to rule out all the other variables here. If you like you could post your linker here so I could briefly check it and see if anything looks like it could be problematic.

Also, the memory layout for MSPM0G1507 and MSPM0G3507 is the same, so if you have a launchpad on hand you should be able to get the same behavior on both devices.

As another note - I am curious - if you try to connect to CS_DAP and SEC_AP using CCS, are you able to do so, or do these also fail?

Have you checked that the binaries generated from earlier toolchains compared to the new one are the same?

Hi Dylan,

yes the linker file stayed the same. No change here. Only Toolchain and CCS. And it might be the toolchain or sysconf generated files..

I`ve got a launchpad MSPM0G3507. I´ll give it a try.

What I`m going to do:

1. Use CCS 20

2. switch back to SDK 2.2.0.05 and sysconf 1.21.1 

3. build and run as I normally would

Isn´t the device detected upon starting the debug session? So can I run the MSPM0G1507 hexfile on the MSPM0G3507 without changing the project settings? I want the changes to be as minimal as possible.

I`ll give it a try...

My linker file:

MSPM0G1507.zip

Thanks!

Best regards

Steffen

How can I connect via CS_DAP and SEC_AP?

I ve not compared the hexfiles. But I will. I compile it with new and old SDK and sysconf.

The difference between hexfiles is minimal:

Hexfiles.zip

Worked like a charm. no problems here but different HW. On Launchpad PA18 isn`t used for other purposes.

If got a hunch:

My board is in BSL mode. PA18 is high on startup. Does that invoke the BSL?

Why is it in now in BSL? Maybe CCS 20 does not clean or write NONMAIN so the BSL can`t be disabled.

I`ve attached my target conf and launch session

targetConfigs.zip

I`ve pulled PA18 high on the launchpad in order to get the same condition as on my board but the launchpad is still programmable.

I think I`ll have to wait until I recieve the samples...

Hi Steffen,

Thanks for posting your info here this helps a lot. So using beyondCompare, I can see the .hex files are identical. So as long as you've provided me with the correct files, these would not be the source of your issue. Additionally looking at your linker file, it seems fine to me as well, I highly doubt it is causing any issues.

To be clear about your results, you mean that when using the old SDK + old sysconfig in CCS20, the example is working as expected without issue, correct?

To answer the questions above:

1) How do I access CS_DAP and SEC_AP? 

You can do this in CCS20 by going to the debug tab and launching a projectless debug with the device connected. Then you can right click on "CORTEX_M0P", and click show all cores. CS_DAP_0 and SEC_AP should appear now. You can now right click and hit connect. Assuming the device is functioning properly and the hardware is correct, you should always be able to connect to CS_DAP. I often use this to test if the device is alive at all.

2) Is the device detected at the start of a debug session?

While CCS can fetch the device type when you use a launchpad with an XDS110, it wont auto detect the connected device and switch for you. To ensure that you are generating the linker for the correct device you can open sysconfig, expand the device view in the top right corner, and you can hit switch to change the device and ensure that the right one is selected.

3) My PA18 is pulled high on startup, does this invoke BSL?

Yes it does. You need to disable the BSL invoke pin or change it by reprogramming NONMAIN. Mind that if you try to change this setting while already using hardware that pulls PA18 high, you will still start up in BSL mode and will need to reset the device for the BSL invocation disable to take effect. 

I see you also mention thta CCS 20 does not clean or write to NONMAIN so BSL cant be disabled - looking at your launch.json file, it looks like MAIN and NONMAIN are set to be erased. You can double check and change this by going to your project properties -> debug tab -> select MSPM0 flash settings in category-> select erase MAIN memory only under erase configuration.

I'd highly recommend checking this setting as your launch file does appear to be erasing nonmain, and if you are not writing a valid configuration to it then it would make sense that you are no longer able to access your device.

Hi Steffen,

Thank you for posting your findings here. Were you ever able to try connecting to CS_DAP and/or SEC_AP? One more thing you could try with the bricked devices is to hold the device in reset before powering the device on, then apply power to the device, then follow the steps to factory reset, holding the device in reset until the factory reset script prompts you to release it.

If you run that "resetDevice" function at the start of main, unconditionally, then it just seems to me that the device is stuck continuously resetting itself. If it is continuously resetting itself then it makes sense that it would fail to connect to a debugger / fail to execute a factory reset.

Maybe I am misunderstanding something, you could post the code snippet in a response if I am misreading this.

Hi Dylan,

no I wasn`t able to connect via CS_DAP or SEC_AP.

What I don`t get is that even if the device constantly resets itself the debugger holds it in reset and no code is executed?!

I`ll try the factory reset when I´m back in that state for now I`m happy that I´ve found the root of the problem.

Code snippet:

Best regards

Steffen

How are you determining that no code is executed?

Once you flash the device with the code you show above, the device will continually reset itself. Then when you try to reconnect with the debugger, it wont be able to connect because the POR will cause the SWD error that you mention in your top level post. 

To get around this, I mention above that you could hold the device in reset before powering on, which would prevent code from being executed, then when you factory reset you no longer continuously reset and should be able to successfully reprogram the device.

Ok yeah your right! Thanks!