MCF5329 & 64MB SDRAM

[JD1z]

Hi

We have 2 x 32MB SDRAMs on our product. We have now upgraded the SDRAM to 64MB each(same manufacturer (ISSI)). As far as the hardware is concerned the extra address line/s have been connected.

Now I need to enable and use this extra SDRAM. So far I have:-

1. modified the chip select register SDCS0 in bsp_init.c to 0x40000019 and rebuilt the bsp library.
2. modified the __EXTERNAL_SDRAM_SIZE .lcf linker file being used in our project

To test this extra SDRAM I try and allocate some some by using _mem_alloc_from(). I get NULL.

Also tried writing directly in the code with the following line "*(long *)0x43000000 = 0x5A;"

Do I need to change/configure anything else?

Using Codewarrior v6.3, MCF5329 and MQX version 2.5

Thanks

[TomE]

Read and understand section 18.3.1 in the Reference Manual. Match that up with the Data Sheet for the SDRAM chip.

Then you'll have to find either the code that sets up the ADDR_MUX bits in SDCR and change it to  to match the chip, or the definitions (in a header or configuration file) where you tell the system the address multiplexing of the RAM chip so it can generate the proper values for that register.

The SDRAM controller has to be set up by the earliest bootstrap code. What bootstrap are you running, or is that built as part of MQX? If you're looking at the BSP part of the OS then you may be looking in the wrong part of the system.

Tom

[JD1z]

Hi Tom

Thanks for the advice. I went back and read section 18 in the ref manual.

I modified:-

1.  the ADDR_MUX, it was 00 and needed to be 01 for 16M x 32 bit (13x9x4).

2. the CSMR0[BAM] & CSMS1[BAM] to 0x03FF for 64MB

3. Bit 17 of SDMR, it was being set and ref manual states its Reserved and must be cleared. Not sure what difference this would have made as the previous setup with 2 x 32MB worked.

With these changes I've had partial success, I can now  R/W all 64M of the second SDRAMbut only the first 32MB of the first SDRAM from 0x40000000.

I am running a debug build using the iSystem blue box iC300HS. The file I modified was  .ini file.

I shall continue looking into it.

Here's the file it has the original values commented out:-

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

// Turn on RAMBAR at address 80000000
//  MCF5329DE.pdf - RAMBAR cannot be read through BDM, returns 0x00000000
R RAMBAR L 0x80000221
// Set VBR to the beginning of what will be in internal SRAM
// MUST follow vector table from linker command file
R VBR L 0x80000000 
// Set CACR = 0
// Disable cache
R CACR L 0x00000000
// Set ACR0 = 0x00000000
R ACR0 L 0x00000000
// Set ACR1 = 0x00000000
R ACR1 L 0x00000000
// Disable watchdog timer
A (0xFC098000) W 0x0000

// Init CS0
A (0xFC008000) L 0x00000000             //32MB & 64MB donot change this one
A (0xFC008008) L 0x000021A0             //32MB & 64MB
//A (0xFC008004) L 0x00FF0001           //32MB
A (0xFC008004) L 0x03FF0001             //64MB

P 100                                   // delay

// Init CS1
//A (0xFC00800C) L 0x10000000           //32MB
//A (0xFC008014) L 0x002A3780           //32MB
//A (0xFC008010) L 0x00FF0001           //32MB
A (0xFC00800C) L 0x20000000             //64MB 
A (0xFC008014) L 0x000021A0             //64MB
A (0xFC008010) L 0x03FF0001             //64MB

// SDRAM Initialization

P 200                                   //delay 200

A (0xFC0A4065) B 0x3F                   // MSCR_SDRAM

//A (0xFC0B8110) L 0x40000017           // SDCS0  32MB?? 17 is 16MB
A (0xFC0B8110) L 0x40000019             // SDCS0  64MB
//A (0xFC0B8114) L 0x60000019             // SDCS1  64MB starting from 0x60000000
A (0xFC0B8114) L 0x44000019             // SDCS1  64MB string from 0x44000000

A (0xFC0B8008) L 0x61222A00             // SDCFG1
A (0xFC0B800C) L 0x53730000             // SDCFG2

// Issue PALL
//A (0xFC0B8004) L 0xC0120002           // SDCR   32MB
A (0xFC0B8004) L 0xC1120002             // SDCR   64MB

// Issue LEMR
//A (0xFC0B8000) L 0x008B0000           // SDMR   32MB
A (0xFC0B8000) L 0x00890000             // SDMR   64MB

// Write mode register
// A (0xFC0B8000) L 0x058D0000          // SDMR   32MB

P 1000                                  //delay 1000

// Issue PALL
//A (0xFC0B8004) L 0xC0120002           // SDCR  32MB
A (0xFC0B8004) L 0xC1120002             // SDCR  64MB

// Perform two refresh cycles
//A (0xFC0B8004) L 0xC0120004           // SDCR    32MB
//A (0xFC0B8004) L 0xC0120004           // SDCR    32MB
A (0xFC0B8004) L 0xC1120004             // SDCR    64MB
A (0xFC0B8004) L 0xC1120004             // SDCR    64MB

//A (0xFC0B8000) L 0x008B0000           // SDMR    32MB
A (0xFC0B8000) L 0x00890000             // SDMR    64MB

//A (0xFC0B8004) L 0x50120000           // SDCR    32MB
A (0xFC0B8004) L 0x51120000             // SDCR    64MB

P 100                                   //delay 100

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

regards

Jaswinder

[JD1z]

No comments  next to the code....I agree with you that this file has been copied and modified. It is still named SEN5329.ini which is for the SENTEC board.

I'm a little confused on how  it all fits together.

This project is built in winIDEA, under build files I have 2 linker files one for FLASH and other for SDRAM. Not too bothered about the flash as I want to run code from SDRAM for now. The 2 files are extflash.lcf and m5329evb.lcf

The project is also pulling in 5 libraries  (CodeWarrior projects)

cobra5329.a  (board support)

mfs.a

mqx.a

rtcs.a

usb.a

The cobra5329 project contains the mcf5329_init() which initialises the CPU speed, chip selects and is called from vectors.cw  boot sequence before calling the runtime application startup code. This function only initialises  if it hasn't already done so by a control tool

The project in winIDEA also has an initialisation file SEN5329.ini (posted previously).

If I'm running from SDRAMdo I only need to modify the SEN5329.ini & m5329evb.lcf.?

I have modified the mcf5329_init() to match the ini file and rebuilt cobra5329.a lib, but I do think this is not necesary for now.

[TomE]

I wrote:

> My guess is that maybe one of the other chips

After sleeping on it my guess is that it is an old fashioned bug in that initialisation file.

When you said that only the first 32M of the first chip "worked", is that from the debugger after loading or after starting your code?

You should try reading and writing to RAM after your code is loaded (and that ".ini" file has done its work). I'd expect you to have unique access to the whole 128M then. Then run parts of your code (adding breakpoints) and see when the second 32M stops working. Then zero in on the code that is disabling that RAM.

I've never worked with that development system so I have no idea how it is all put together. Check for some documentation that tells you how it all works, and what bits are responsible for what hardware, platform, board and chip setup.

Tom

[JD1z]

The issue I think is in the my project linker and/or the ini file. I access the memory from my application. So for the first sdram I can read/write 0x40000000 to 0x41FFFFFF and not 0x43FFFFFF as I would expect. I'm off work now till after new year but will keep looking at it as its starting to bug me now.

Thanks for all your help Tom.