On reset processor behaves differently

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

On reset processor behaves differently

2,163 Views
habha
Contributor I

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 

Labels (1)
0 Kudos
7 Replies

746 Views
RichTestardi
Senior Contributor II

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

0 Kudos

746 Views
habha
Contributor I

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.

0 Kudos

746 Views
habha
Contributor I

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 

0 Kudos

746 Views
RichTestardi
Senior Contributor II

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

 

 

0 Kudos

746 Views
habha
Contributor I

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
0 Kudos

746 Views
RichTestardi
Senior Contributor II

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

0 Kudos

746 Views
RichTestardi
Senior Contributor II

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.

 

 

 

0 Kudos