Resetting ColdFire V1 with firmware

cancel
Showing results for 
Search instead for 
Did you mean: 

Resetting ColdFire V1 with firmware

Jump to solution
1,050 Views
markthedark
Contributor III

I would like to fully reboot a ColdFire V1 MCU (MCF51JE256) using a firmware instruction. I was able to do this to a V2 MCU using the SOFTRST bit in the RCR (Reset Control Register), but this register doesn't seem to be present in the V1 cores.

 

Is there a proper way to achieve this with a V1 core?

 

Thanks,

Mark

Labels (1)
0 Kudos
1 Solution
435 Views
markthedark
Contributor III

Hello Tom and Fang.

I am finally back to working on this feature of our product! Thank you for all your input and information.

I successfully implemented the following solution proposed by JimDon‌ in the post that was mentioned above.

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

The beauty of this solution is that if you are debugging, it will halt the debugger. Perfect.

Thanks again all!

Mark

View solution in original post

0 Kudos
7 Replies
435 Views
TomE
Specialist I

Fang Li Employeewrote:

> For V1, we recommend to use the ILLEGAL opcode (0x4AFC) to implement the soft reset.

Would you like to check that advice?

Tom

0 Kudos
435 Views
TomE
Specialist I

Fang Li Employeewrote:

> For V1, we recommend to use the ILLEGAL opcode (0x4AFC) to implement the soft reset.


If that worked I would have recommended it in my original post. I read the MCF51JE256 Reference Manual (Rev 2) before posting, and it states:

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).

Also:

Table 5-2. ColdFire Exception Vector Table1 (Continued)
The execution of the ILLEGAL instruction (0x4AFC) always generates an illegal instruction
exception, regardless of the state of CPUCR[30].

Also:

Table 5-4. SRS Register Field Descriptions
Illegal Opcode — Reset was caused by an attempt to execute an unimplemented or illegal opcode. This includes
any illegal instruction [except the ILLEGAL (0x4AFC) opcode...

A quick check through the other MCF51 variants to see if the ILLEGAL instruction can be used to cause a Reset on some of them:

MCF51JE: Illegal Instruction can't cause Reset.
MCF51AC: Same
MCF51AG: Same
MCF51CN: Same
MCF51EM: Same
MCF51JF: Same
MCF51JM: Same
MCF51JM: Same
MCF51MM: Same
MCF51QE: Same
MCF51QM: Same

Tom

0 Kudos
436 Views
markthedark
Contributor III

Hello Tom and Fang.

I am finally back to working on this feature of our product! Thank you for all your input and information.

I successfully implemented the following solution proposed by JimDon‌ in the post that was mentioned above.

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

The beauty of this solution is that if you are debugging, it will halt the debugger. Perfect.

Thanks again all!

Mark

View solution in original post

0 Kudos
435 Views
miduo
NXP Employee
NXP Employee

Hi,

Yes, as Tom mentioned, the ColdFire V1 is quite different from other ColdFire family. For V1, we recommend to use the ILLEGAL opcode (0x4AFC) to implement the soft reset.

0 Kudos
435 Views
TomE
Specialist I

Different core, different features. The CF1 core is targeted as being an HCS12 replacement, and usually has peripherals (and peripheral control programming) derived from those families. For instance the GPIO pins are usually forced to be UART pins when the UART is enabled, unlike the CF2 family where the pins have to have their functions explicitly selected elsewhere.

Read up on CPUCE[IRD].

Read section "5.3 Microcontroller Reset". That gives all the available "reset sources".

You have the options of looping a GPIO to the Reset pin, letting the COP Watchdog bite or executing an illegal instruction.

On restart you check the SRS to see what caused the reset (expected or otherwise) and take any appropriate action.

Previous slightly related topic from 2009:

https://community.nxp.com/message/58771?commentID=58771#comment-58771

Tom

0 Kudos
435 Views
markthedark
Contributor III

Thanks Tom. This is helpful.

As for executing an illegal instruction, can you suggest a value to use?

Cheers,

Mark

0 Kudos
435 Views
TomE
Specialist I

Section "5.3.2 Illegal Opcode Detect (ILOP)".

I'd suggest "STOP" or "HALT" if you have SOPT or XCSR set to appropriate values in your system, or for your "illegal instruction" write one of them to the appropriate value. XCSR access requires a WDEBUG sequence, so is tricky. SOPT is write-once, so you can't change it if you've got it set to enable this mode.

Otherwise, the instruction set reference doesn't tell you what instruction formats are "illegal". I'd try an "ADD" with an OPMODE value other than the two listed.

This came up 5 years ago and a suggestion was made then:

https://community.nxp.com/message/116068?commentID=116068#comment-116068

Tom