topic Re: On reset processor behaves differently in ColdFire/68K Microcontrollers and Processors

On reset processor behaves differently

habha — Thu, 02 Apr 2009 05:21:50 GMT

I have programmed M5234 using codewarrior 7.1. It is behaving rightly when I run code from codewarrior GUI, but once I reset the processor it goes crazy.

Its the same with RAM or Flash.

My program did configure eTPU channel to output PWM(1Khz,50%) and toggling another eTPU GPIO channel. When run from CW(CodeWarrior) its working as intended.

Once I restart PWM output will 250Hz, 25%. whatever I program this PWM output will be the same on reset.

Can anybody suggest me where I am going wrong. Am I forgetting to initialize something?

Thanks

Re: On reset processor behaves differently

RichTestardi — Thu, 02 Apr 2009 05:41:04 GMT

The time I typically see a difference between running in the debugger and running after a reset is if my debugger CFG file is initializing something I'm forgetting to (re)initialize in the code. The debugger will run thru the lines of the CFG file after the MCU is reset and before the MCU starts running. That doesn't happen after a normal reset. (I actually use this to *detect* if I am running in the debugger, BTW.)

Is there a lot of stuff in your CFG file?

I've even seen CFG files turn off watchdog timers... If you run in the debugger, everything is fine... If you run outside of it, boom, the watchdog pops and you magically reset (over and over) in a few milliseconds.

It's also a good idea to read the RSR on boot and do something special (detectable) if you reset for any unexpected reasons, like the watchdog popping, otherwise those things can be hard to detect. (I had unexpected LVD resets occurring on another MCU as we powered up, and did not track them down until I put in special instrumentation to read RSR -- I then flashed LEDs to indicate it had happened before proceeding with the boot.)

-- Rich

Re: On reset processor behaves differently

habha — Thu, 02 Apr 2009 06:04:20 GMT

Hi Rich,

I can see your point about ".cfg". But how to include .cfg implementation in our image?

I thought of including it in "_startup()" of startcf.c . But some syntax errors occured.

Re: On reset processor behaves differently

RichTestardi — Thu, 02 Apr 2009 06:18:38 GMT

What's in your CFG file? We'll need to make sure each line has a corresponding line in your startup code, or that the line is unnecessary.

Just as an example, if your CFG file had a line like:

; Turn off WCR
writemem.w 0x40140000 0x0000

Then you'd be running w/o a watchdog under the debugger (since the debugger set WCR to 0x0000), but with a watchdog otherwise (since WCR defaults to 0x000f, according to the RM).

If you want to set the same state in your initialization code, you'd first search your header files for the register at that address and you would find (in MCF5234_WTM.h?):

#define MCF_WTM_WCR (*(vuint16*)(&__IPSBAR[0x140000]))

So you would want to set:

MCF_WTM_WCR = 0;

In your startup code.

Does that make sense?

Basically, you want to not depend on the CFG file when you are running, and unless you've coded up watchdog routines, you probably don't want the watchdog enabled.

Re: On reset processor behaves differently

habha — Thu, 02 Apr 2009 10:50:19 GMT

Hi Rich,

I could replace all the code of ".cfg" using "C" statements instead of asm.

"writecontrolreg 0x0801 0x00000000" --- how to write this in "C" or "asm"

i understand "writemem.b 0x40100040 0xE1" --> "*(uint8_t *) (0x40100040) = 0xE1" in "C"

Thanks

Re: On reset processor behaves differently

RichTestardi — Thu, 02 Apr 2009 11:22:27 GMT

You probably want to be careful about what you copy from the CFG file to your .c or .asm file -- some of the lines in the CFG are only appropriate for debugging (for example, I actually turn off processor status signals when not under the debugger, to reduce emi)... My usual approach is to remove unnecessary code from the CFG, and to copy only what I really need to C.

> "writecontrolreg 0x0801 0x00000000" --- how to write this in "C" or "asm"

The control registers are likely already set up in your C code... You can see them listed in table 3-5 of your Reference Manual. 0x801 is the VBR and 0xC05 is RAMBAR, and they are both written with asm MOVEC. My guess is your startup code already sets these. Obviously if you point VBR somewhere other than flash, you have to make sure all the vectors are copied there before you enable interrupts.

If you have to do it yourself, it looks something like:

move.l #0x00000000,d0
movec d0,VBR

And you have to be sure your assembler/compiler is set to the right MCU or you can silently generate the wrong opcode for the movec. And the RAMBAR name might be RAMBAR0 or RAMBAR1 or something else -- I haven't used that MCU.

Note that the RAMBAR CPU space register is distinct from the SCM MCF_SCM_RAMBAR -- the former is for CPU access to SRAM and the latter is for peripheral access to SRAM. You may have to set both during startup.

-- Rich

Re: On reset processor behaves differently

habha — Wed, 08 Apr 2009 02:16:00 GMT

Hi Rich,

I have added all the code in ".cfg" into my ".c" file before initialising hardware. But still it is not working.

Here is my ".cfg" file:

-------------------------------------------------------------------------------------

ResetHalt

Delay 200

Stop

; Set VBR to the beginning of what will be SDRAM

; VBR is an absolute CPU register

; SDRAM is at 0x00000000+0x0400000

writecontrolreg 0x0801 0x00000000

; Set RAMBAR = 0x20000001

; RAMBAR is an absolute CPU register

; This is the location of the internal 64k of SRAM on the chip

writecontrolreg 0x0C05 0x20000001

; Set PAR_SDRAM to allow SDRAM signals to be enabled

writemem.b 0x40100046 0x3F

; Set PAR_AD to allow 32-bit SDRAM if the exteranl boot device is 16-bits

writemem.b 0x40100040 0xE1

; Turn off WCR

writemem.w 0x40140000 0x0000

; 1MB ASRAM on CS1 at 0x30000000

writemem.w 0x4000008C 0x3000 ; CSAR1

writemem.l 0x40000090 0x000F0001 ; CSMR1

writemem.w 0x40000096 0x3D20 ; CSCR1

; 2MB FLASH on CS0 at 0xFFE00000

writemem.w 0x40000080 0xFFE0 ; CSAR0

writemem.l 0x40000084 0x001F0001 ; CSMR0

writemem.w 0x4000008A 0x1980 ; CSCR0

delay 100

; 16 MB SDRAM

; Like the 5307 and 5407 Cadre 3 boards, this board uses DCR,DACR, DMR to access SDRAM

writemem.w 0x40000040 0x0446 ;

writemem.l 0x40000048 0x00001300 ;

writemem.l 0x4000004C 0x00FC0001 ;

writemem.l 0x40000048 0x00001308 ;

writemem.l 0x00000000 0x00000000 ;

; Wait a bit

delay 100

; Initialize SDRAM with a write

writemem.l 0x40000048 0x00009300;

writemem.l 0x40000048 0x00009340;

writemem.l 0x00000400 0x00000000;

; Wait a bit more

delay 600

writemem.w 0x40140000 0x0000 ; disable the watchdog timer in WCR

-----------------------------------------------------------------------------------------

I have added the following lines before initialising hardware:

----------------------------------------------------------------------------------------

asm

{

move.l #(__IPSBAR + 1),d0

move.l d0,0x40000000

}

(*(uint8 *)0x40100046) = 0x3F;

(*(uint8 *)0x40100040) = 0xE1;

MCF_WTM_WCR = 0;

(*(uint16 *)0x4000008C) = 0x3000;

(*(uint32 *)0x40000090) = 0x000F0001;

(*(uint16 *)0x40000096) = 0x3D20;

(*(uint16 *)0x40000080) = 0xFFE0;

(*(uint32 *)0x40000084) = 0x001F0001;

(*(uint16 *)0x4000008A) = 0x1980;

(*(uint16 *)0x40000040) = 0x0446;

(*(uint32 *)0x40000048) = 0x00009340;

(*(uint32 *)0x00000000) = 0x00000000;

(*(uint32 *)0x00000400) = 0x00000000;

(*(uint32 *)0x4000004C) = 0x00FC0001;

Processor works wrongly when I reset it.

Thanks for your support.

Hari

Message Edited by habha on 2009-04-07 08:23 PM

Message Edited by habha on 2009-04-07 08:24 PM

Re: On reset processor behaves differently

RichTestardi — Thu, 29 Oct 2020 09:16:36 GMT

Hi,

I could not read your post -- the line endings looked like they got munged.

I definitely would not suggest just translating the entire cfg file to C since what you really want to do depends a lot on what the rest of your initialization sequence does, and many of the lines of the cfg file may be superfluous anyway...

However, if you want a literal translation, I believe it is:

volatile static int g;asm {  move.l #0x00000000,d0  movec d0,VBR  move.l #0x20000001,d0  movec d0,RAMBAR}*(vuint8 *)0x40100046 = 0x3F;*(vuint8 *)0x40100040 = 0xE1;*(vuint16 *)0x40140000 = 0x0000;*(vuint16 *)0x4000008C = 0x3000;*(vuint32 *)0x40000090 = 0x000F0001;*(vuint16 *)0x40000096 = 0x3D20;*(vuint16 *)0x40000080 = 0xFFE0;*(vuint32 *)0x40000084 = 0x001F0001;*(vuint16 *)0x4000008A = 0x1980;for (g = 0; g < 100*100000; g++) ;*(vuint16 *)0x40000040 = 0x0446;*(vuint32 *)0x40000048 = 0x00001300;*(vuint32 *)0x4000004C = 0x00FC0001;*(vuint32 *)0x40000048 = 0x00001308;*(vuint32 *)0x00000000 = 0x00000000;for (g = 0; g < 100*100000; g++) ;*(vuint32 *)0x40000048 = 0x00009300;*(vuint32 *)0x40000048 = 0x00009340;*(vuint32 *)0x00000400 = 0x00000000;for (g = 0; g < 600*100000; g++) ;*(vuint16 *)0x40140000 = 0x0000;

Note especially that you should disassemble the movec instructions and ensure that they refer to registers 0x0801 and 0x0C05.

My recommendation would be to a) understand everything in your cfg file, and then b) remove all lines that are unnecessary for your configuration, and then c) incorporate the remaining lines into your C initialization which were not otherwise already handled in a different way already.

-- Rich