MSPM0G1507: JLink MCU Reset

Hi Lucas,

We do not have an example of a script for this, you would need to implement this yourself. 

Using the script and exact register accesses it uses, you could not perform a higher level reset (one that actually resets some peripherals).

Writing your own script, you have two options:

1) Reset via the PWR-AP - Similarly to the above script, write to the SPREC register in the PWR-AP. Setting bit 0 can initiate a PWR-AP reset which resets a bit more than a CPU reset, including the clock system. I do not recommend this route as it has less documentation and is the same amount of work as the next one as far as I can tell.

2) Reset via the SYSCTL module - write to the SYSCTL registers in the CPU to reset the device. This will allow you to choose which reset level you want, just by accessing the device with the debugger and rewriting some bits in the SYSCTL registers.

I have tried the SYSCTL register as well as the reset pin holding it low for less than 1 second. However, I am having difficulty getting the CPU to halt immediately at the start of the Reset Handler.

In the original example we used:

JLINK_MEM_WriteU32(_DEMCR_ADDR, (_DEMCR_VC_CORERESET | _DEMCR_TRCENA)); // Set vector catch on reset (to halt the CPU immediately after reset)

To do this, but this does not work with the other types of reset.

Hi Lucas,

You can also use our PWR-AP as Dylan previously mentioned to do the same thing rather than using the DEMCR.

It is the fourth access point in our device and the register known as the DPREC at address 0x00 can modify the behavior post reset. By setting the RST CTL bits (14:16) as  001b, it will force the device into the reset handler and remain there post reset.

I'm curious though, upon using the DEMCR register and executing a reset where does it end up? Does it reset and continue running?

When I reset using AIRCR.SYSRESETREQ, it only resets the core and DEMCR behaves as expected by halting it in the reset handler. However, when I use SYSCTL or the reset pin, it does not halt in the reset handler and when it stops, it is already in some iteration of the main loop. In the JLink script function, reading DEMCR after resetting using SYSCTL or the pin, it reads the values ​​0xFFFFFFFF or 0x0. I tried using RST CTL together with resetting using SYSCTL and the pin, but I didn't really understand when I should make the change and what to do next. That's why I was unsuccessful.