Reset MCF51JM

[ralu]

How can i soft reset MCF51JM

In spec sais : 

Also, if any value other than 0x55 or 0xAA is written to SRS, the microcontroller is immediately reset.

This does not work for me at least in debug mode, so how can i reset CPU?

 

[TomE]

Watchdogs and debugging are always a problem.

Some CPUs allow debugging with a watchdog by having the watchdog stop when the debugger stops the CPU.

Other ones, like the MCF5329 which I'm familiar with have a "HALTED" configuration bit, which as well as having the watchdog stop when the debugger halts the CPU, disables the "write once" operation of the debugger control registers, so the debugger can turn the watchdog on and off as required.

The MCF51JM doesn't seem to have any of those capabilities.

So it looks like you can't (or can't easily) debug code with the watchdog.

To fix this you normally have to write your startup code to find out somehow if you're running under the debugger or not, and to disable the watchdog when you are. Otherwise, the "debugger startup script" should disable the watchdog.

> How can i soft reset MCF51JM

Back to your original question. The MCF5329 has a "Soft Reset" bit in a register. The MCF51JM doesn't. So you have to use the Watchdog to cause a soft reset, unless you've disabled it or it is disabled under the debugger.

You really don't want thave the CPU reset itself out from under the debugger or you'll probably lose control of it. "Debugging resets" is as problematic as "debugging the watchdog". You can reset the CPU from the debugger, so that what you should do.

You should probably write your code to try and reset using the watchdog, and then sit in a loop waiting for the reset. When you're debugging it, when it is stuck in a loop that means you have to manually reset it from the debugger.

If you want to be able to reset it without using the debugger, connect a GPIO pin back to the Reset pin and drive that.

You may want to be able to debug resets, watchdogs and all that, but you may be using a chip that simply doesn't support that, and requires you to make compromises. Maybe the chip and the debugger can conspire to do this well enough, but you can't find any documentation telling you how to do this. Check your debugger/development documentation. Maybe someone else here who has used this chip knows if this can be done.

Tom

[ralu]

So reset is just skipped im my case whith debugger , but in production writing 0xFF in SRS will reset CPU?.

(i need reset because i am doing bootloader) 

[JimDon]

An ILOP will cause a reset under th following conditions:

5.3.2 Illegal Opcode Detect (ILOP)
The default configuration of the V1 ColdFire core enables the generation of an MCU reset in response to
the processor's attempted execution of an illegal instruction (except for the ILLEGAL opcode), illegal line
A, illegal line F instruction or the detection of a privilege violation (attempted execution of a supervisor
instruction while in user mode).
The attempted execution of the STOP instruction with (SOPT[STOPE] = 0 && SOPT[WAITE] = 0) is
treated as an illegal instruction.
The attempted execution of the HALT instruction with XCSR[ENBDM] = 0 is treated as an illegal
instruction.
The processor generates a reset in response to any of these events if CPUCR[IRD] = 0. If this
configuration bit is set, the processor generates the appropriate exception instead of forcing a reset.

Also ILAD:

5.3.3 Illegal Address Detect (ILAD)
The default configuration of the V1 ColdFire core enables the generation of an MCU reset in response to
any processor-detected address error, bus error termination, RTE format error or fault-on-fault condition.
The processor generates a reset if CPUCR[ARD] = 0. If this configuration bit is set, the processor
generates the appropriate exception instead of forcing a reset, or simply halts the processor in response to
the fault-on-fault condition.
5.4

[JimDon]

This should work as a reset on the V1, it's a an FSAVE instruction which is not implemented:

   asm {     dc.w 0xF300        }

[JimDon]

I found some other details here.

For one thing, you really need to this:

          move.l  #0,d0
          movec   d0,CPUCR

To insure it does not cause an exception instead of  a reset.

Also, it seems you can just use the HALT instruction. When debugging, it will just cause a break point. If not debugging, it will reset the V1 MCU.

#define MCURESET   asm {\
          move.l  #0,d0\
          movec   d0,CPUCR\
          HALT\
}

[TomE]

> but in production writing 0xFF in SRS will reset CPU?.

As long as you don't disable the watchdog.

This is something you should be able to test very easily. Write some code that attempts a reset and shows what it is doing on a serial port. LED, LCD or whatever you have, load it and run it. It will do what you expect or it won't.

Tom