MCF54416 UBOOT Debugging

[gachen]

Hi,

    I have been debugging the problem for a while. So the description here will be a little bit long.

    download u-boot to spi flash and system can't boot.

    1. using CodeWarrior's "load memory" to load uboot's first 1K to internal ram. we can single step while pc is still pointing to the internal SRAM. one it jump to the DDR RAM. system died.

     2. using CodeWarriros's "load memory" to load the uboot's first 1k and before uboot's Jump to external ram (0x47e00400), using CodeWarrio's "loading memory " to load uboot to external ram, starting from 0x47e00000. still failed . so using CW's "saving memory", found the content of the DDR RAM is different to uboot.bin.  I tried to stored three times, but three results are different and none of them is correct. FAE from freescale told me that DDR RAM reading from BDM is not trustable, but I am suspicious about this.

    3. we got a working project from freescale and this working project is using DDR RAM to excute. So after this project is running, we stop the system, and download the uboot.bin by "load memory" to DDR RAM.  using "storing memory" again and found that the content of the DDR RAM is matching uboot.bin. and "change program counter" to 0x47e00400, at least we saw the following from the com port.

U-Boot 2009.08 (Jul 01 2011 - 14:49:16)

CPU:   Freescale MCF54416 (Mask:a1 Version:1)
       CPU CLK 250 MHz BUS CLK 125 MHz FLB CLK 62.500 MHz
       INP CLK 50 MHz VCO CLK 500 MHz
Board: Freescale M54418 Tower System
SPI:   ready
DRAM:  128 MB

so I would conclude that DDR RAM is causing the problem. and once DDR RAM is right configured, uboot will starts to work.(may have other bugs....) I have tried to compared the DDR_CRs between uboot and working project. And it showes that only DDR_CR41 is different. uboot.bin is using 0x00C80064, and working project is using 0x00000064. What this meaning? any register will also affects DDR setting?

Any suggestion to this ?

Br, Chen Gang

[TomE]

> And it showes that only DDR_CR41 is different. uboot.bin is using 0x00C80064,

> and working project is using 0x00000064.

The obvious thing to do is to change U-Boot to match the "working project". Have you tried that? Did it start working?

> What this meaning?

The Reference Manual has a chapter on the SDR/DDR controller. It has a section listing all the registers and describing all the fields in all the registers.

That one is described as being for:

    21.4.42 DDR Control Register 41 (DDR_CR41)

    31–16: TDLL: DLL lock time in cycles.

There's a BIG CLUE to your U-Boot problem where it then says:

             Note: This field must be cleared.

=============

There are 49 control registers. I've never seen a controller with so many registers! All the other manuals I've seen have a big section detailing how to set up the controller. Not this one, here's all it says:

21.6 Initialization/Application Information
The memory controller requires a sequence for correct operation after power to the microcontroller and
memory devices is stable. When initialized, the memory controller automatically initializes the memory
devices.
The procedure to initialize the memory controller is as follows:
1. Issue write register commands to configure the DRAM protocols and the settings for the DCC.

   Keep DDR_CR09[START] cleared during this initialization step.
2. Set DDR_CR09[START]. This triggers the memory controller to execute the initialization
    sequence using the parameters written into the registers. The memory controller waits for the PHY
    to indicate that the PHY and memory devices are ready to accept commands.

That's ALL it says. Are there any Application Notes to help set up the other 48 registers for this part?

Tom

[gachen]

It turned out be the clock source matters, after changing the clock source from VCO to CORE, u-boot starts to work. DDR_CR41 doesn't matter.