SDRAM controller question

[carrie]

Our SOC is embedded an ARM CPU. It's strange that the reset signal of SRAM controller must be de-asserted before CPU reset, or the system can't be boot up. Does anyone know the reason? Thanks in advance.

 

[farmerwang]

Your description of the problem is too simple, can you check the following items?

1. Do you implement remap in your SoC?
2. What's the boot up sequence? Do you allocate enough time for the SDRAM controller to do device initialization?
3. Does your boot code check the MC before jumping to SDRAM address?

 

[IanP]

Use proper reset IC that will give you clean 50-500ns reset pulse (DS1232, ...many of them on the market).
Did you say SDRAM or SRAM?
For SRAM there is additional supervisory IC, such as DS1210, which will take care of the CS line during reset time.

 

[carrie]

Thanks for farmerwang and IanP's kindly reply.

We do implement remap in our SOC. The flash is remapped to address 0x0 when boot up.
Then the remap is cleared, and SDRAM is initialized. After that, the processor moves code from flash to SDRAM, and executes code from SDRAM later.

To farmerwang, Since I'm not familiar with SDRAM, could you please tell me what does 'MC' stand for, and when should I allocate time for SDRAM device initialization?

To IanP, Do you means the reset IC will give different reset pulse for processor and SDRAM? In our design, there is a reset generation block, which release SDRAM controller's reset signal earlier than processor's in normal operation mode. but in reset-bypass mode, the two resets are de-asserted at the same time, so causes error.

 

[IanP]

In my post there was obviously typing mistake: it was not ns but ms.
Backt to your question: no, this IC will give you a clean pulse on power-up and if voltage drops below/and comes back above the selected threshold.
From here you can use 1/2 74123 to sustain reset signal for another mseconds and this one can be used for the CPU reset..

 

[carrie]

My maneger said the reset bypass mode is only used for internal debug, and the error is caused by our SDRAM simulation model, so it can be ignored in real application.

This issues is closed now.

 

[tom123]

The reason perhaps is that CPU will access SRAM after reset,

so SRAM's reset bust be de-asserted before CPU's reset is de-asserted.

Our SOC is embedded an ARM CPU. It's strange that the reset signal of SRAM controller must be de-asserted before CPU reset, or the system can't be boot up. Does anyone know the reason? Thanks in advance.