I am getting the following error when trying to flash Failed to resume target process. Not allowed to access registers while running

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

I am getting the following error when trying to flash Failed to resume target process. Not allowed to access registers while running

8,500 Views
davidpotter
Contributor I

Using a custom board, that has been flashed before. Processor, MK20FX512xxx12.  I tried the following command in J-Link Commander, "h", to halt the processor. Doesn't help.

Codewarrior 10.7

I have no compile or PE generate code errors.

Just can't flash the MCU

0 Kudos
5 Replies

4,865 Views
talktrn
Contributor I

Just a comment:  I have a number of programs on a custom K60FX512 board that have been running successfully for over a year using CW10.6 on Win7-64b.  Now the JLink interface is no longer working -- I have two of these, one basic unit and other is JLink Plus.  Both have been in use for several years. Installed CW10.7, same result.

I can still program, etc., using JFlash V4.84 (I know that is old).  Same program can be downloaded and debug using PEMicro adapter, no problems there.

Apparent issue:  switched over to MCUXpresso for a K22F project for a few weeks, using PEMicro Universal Multilink adapter.   It appears that whatever JLink driver got installed killed the CW10.6/10.7 setup.  I got all kinds of errors from not being able to find the JLink adapter, to same error message reported in David Potter's question.

Just installed Segger latest 6.20c, now back to normal.  CW10.6 works again with JLink adapters.

0 Kudos

4,864 Views
BlackNight
NXP Employee
NXP Employee

How did you flash it? That error message indicates that the J-Link isnot able to start the program on the processor (it is already running?).

Erich

0 Kudos

4,865 Views
davidpotter
Contributor I

I got the device flashed as follows:

Tool bar --> Run --> left button click-->  select Debug Configurations-->Edit Target Settings-->Edit Target and

checked Execute on reset, and un-checked Run out of Reset and unchecked Iniitalize target.

I think the main change that made the difference was NOT using the initialization script,

$ProjDirPath/Project_Settings/Debugger/init_kinetis.tcl. I haven't examined exactly is the problem other than certain registers that the script was trying to access were not available while the processor was running. You can see some

evidence of this in the following log message when flashing:


Starting 3rd party flash programming...
INF:
Jlink: CPU could not be haltedINF:
Jlink: CPU could not be haltedINF:
Jlink: Timeout while checking target RAM, RAMCode did not respond in time
Failed to prepare for programming.
Failed to execute RAMCode for RAM check!
Can not read register 16 (XPSR) while CPU is running
Can not read register 20 (CFBP) while CPU is runnin
Starting 3rd party flash programming...
INF:

I haven't examined the .tcl script to see which of those errors or which error in general killed the flashing.

Two more things. I did NOT halt the CPU via the Jlink commander window. I am using a Jlink Segger Plus.

Would be nice to get a deeper understanding of what elements of debugging are failing. But for now, I am

happy to move forward getting useful coding loaded onto the board

0 Kudos

4,865 Views
davidpotter
Contributor I

I have a Segger Jlink plus. I can run Jlink commander and access the processor (though, that is not how I was trying to flash the part).

I have the RUN and Debug connection set to J-Link/J-Link trace.

I tried running a halt command (h) from the J-Link commander window

and then flashing via Codewarrior. That didn’t work, although at least on one occasion, the flashing started and then

hung up. The progress window reported > 70% finished before it hung up.

I haven’t tried to configure Codewarrior to generate a .bin, or .srec file and load the file directly from the Segger commander window.

0 Kudos

3,027 Views
sumit_batra
NXP Employee
NXP Employee
Kinetis MCU family often has specific flash protection byte(s) which may have been overwritten.
"unlock kinetis" command (in the JLink commandline) should help in such cases to unlock the device.
 
0 Kudos