mcf54415 ddr2 config

[angelo_d]

Dear all,

i am trying to initialize a ddr2 connected to mcf5441x. It's a prototype custom board so i may have hardware issues too.

in a start.s i have the following code:

general init here....

move.l        #PPMCR0, %a1

#ifdef CONFIG_DDR     
/* CD46 = DDR */
move.b     #46, (%a1)

/* dddr2 drive strength settings */
move.l     #MSCR_SDRAMC, %a1     
move.b     #1, (%a1)     

/* use vco instead of cpu*2 clock for ddr clock */     
move.l     #MISCCR2, %a1     
move.w     #0xe01d, (%a1)     /* DDR settings */ 
    
move.l     #DDR_RCR, %a1     
move.l     #0x00000000, (%a1)     <------ program crash here
move.l     #0x40000000, (%a1)

move.l     #DDR_PADCR, %a1    
move.l     #0x01030203, (%a1)        
....................‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍

I am executing step by step some init code (BDM step) but once i set DDR_RCR, the program crash and

jumps to 0x10000

=> 0x800017aa <_start+54>: movel #0,%a1@
(gdb) 53-thread-info
53^done,threads=[{id="1",target-id="Remote target",frame={level="0",addr="0x800017aa",func="_start",args=[],file="src/start.S",fullname="/home/angelo/archivio/aziende/sysam/firmware/m68k-apps/cf64k/src/start.S",line="166"},state="stopped"}],current-thread-id="1"
(gdb) 54-stack-list-frames --thread 1 0 21
54^done,stack=[frame={level="0",addr="0x800017aa",func="_start",file="src/start.S",fullname="/home/angelo/archivio/aziende/sysam/firmware/m68k-apps/cf64k/src/start.S",line="166"}]
(gdb) 55-exec-step-instruction
55^running
1: x/i $pc
=> 0x10000: .short 0x0001‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍

I use linux / gdb / openocd for debug, but with P&E tools from windows i get the same exact error.

Every help really appreciated,

thanks

angelo

[angelo_d]

Hi Tom,

thanks,

it's a 128MB ddr2.

well, mainly i start in limp mode seems, and setting up pll before ddr config (unsing vco) seems to work properly.

I have in case an additional question:

Is there around some ddr configurator (excel tool) for this cpu ? Or do i have to go over each controller register looking the datasheet  ?

Thanks

angelo

[TomE]

> Is there around some ddr configurator

There's nothing on the "Documentation" or "Software and Tools" tabs. No App Notes, so I don't think so.

If you're using the same DDR chips and identical hardware design as the Evaluation Board, then you can start with the same initialisation code that board uses.

But you should check absolutely everything (the DDR Data Sheet parameters and the MCF DDR chapter) to make sure the Development Board setup hasn't got any mistakes in it.

If you're changing anything, including any clock speeds, then you need to check it all yourself, and adjust the parameters as necessary.

Did you start from the TWR system? You should be able to look at the U-Boot Sources to see how it sets things up.

Tom

[angelo_d]

Hi Tom,

uhm, i get the ddr2 init of that tower module from u-boot, had to change some bits as for the terminations,

but the rest seems to work reliably with a bus clock of 240Mhz. I hope i don't have to change anything else.

I like this architecture, and, jfyi, i am custodian of u-boot branch together with Alison Wang (Freescale, now NXP likely).

Still learning a lot btw.

I designed with kicad and soldered all at home this mcf54415 based board below. All opensource way, as the similar "amcore" board in my www.sysam.it site. No businness on these boards actually. 

So actually ddr2 init works,

so i am quite happy. In next days i should see linux running on this board, hopefully.

Many thanks for now.

angelo

[TomE]

When you're running under the debugger, it has already set up the CPU clocking and memory controller. There's probably an "XML" file somewhere containing all the control register addresses and the values that have been written into them. The Debugger expects to have done this, and for you to load your RAM-based code that runs AFTER the hardware initialisation.

If you want to run or single-step from the very beginning, then you normally have the startup code detect that it is running under the debugger, and then SKIP OVER all the initialisation that the debugger has already done.

The Debugger normally needs working stack. What RAM is the stack in? Is it in SRAM or DDR2?

Tom