Problem using J-Link while debugging

Stefan,

I have had this occur too. The solution always seems to be associated with something I have done in code or in a configuration.

Aside from the obvious problems with hardware and external bus timing setup issues, you may want to look at some things which can cause the processor to utilize 100% of its execution time. It also seems that when you do a 'power cycle' the state(s) that caused this issue to occur are removed. That is a hint to follow.

I recall reading somewhere that when you download your code it begins running on the processor prior to the debugger gaining control of the processor and stopping it. You have also seen that once you release the debugger the code you loaded continues to execute.

Your code may contain a few while(1){} loops which can be, at times, hard to overcome in gaining processor control. An interrupt could be firing prior to actually having an ISR to vector to (all obvious but tedious to solve).

You may also want to try and verify the syatem and peripheral device settings on a load and a power cycle compared to a failed load when 'the program counter is somewhere in the program'.

Also try to do a flash Erase command prior to executing a Start/Debug and see if that makes a difference.

Stefan,

I have had this occur too. The solution always seems to be associated with something I have done in code or in a configuration.

Aside from the obvious problems with hardware and external bus timing setup issues, you may want to look at some things which can cause the processor to utilize 100% of its execution time. It also seems that when you do a 'power cycle' the state(s) that caused this issue to occur are removed. That is a hint to follow.

I recall reading somewhere that when you download your code it begins running on the processor prior to the debugger gaining control of the processor and stopping it. You have also seen that once you release the debugger the code you loaded continues to execute.

Your code may contain a few while(1){} loops which can be, at times, hard to overcome in gaining processor control. An interrupt could be firing prior to actually having an ISR to vector to (all obvious but tedious to solve).

You may also want to try and verify the syatem and peripheral device settings on a load and a power cycle compared to a failed load when 'the program counter is somewhere in the program'.

Also try to do a flash Erase command prior to executing a Start/Debug and see if that makes a difference.

www.keil.com/.../ulink_hw_reset_sequence.htm