MCF54452 SDRAM Reset lock

[Kafre]

Hello everybody,

We have a design based on MCF54455EVB with:

- MQX 3.7 (MFS, RTCS and SHELL) with Codewarrior for MCUs 10.1.

- MCF54452 MCU at 200Mhz.

- DDR2 SDRAM, MT47H32M16 (8Meg x 16 x 4 Banks) from Micron.

- RESET CIRCUIT, TPS3305-18D from Texas Instruments.

- We are also using other elements like an external flash, etc. (NA)

The connection of the SDRAM memory with the MCF is pretty straight; as defined in the Application Note AN3522 (DDR2 SDRAM in the Coldfire MCF5445x Microprocessor). We have only added a 100Ohm resistor between SCCLK and #SDCLK and a 22Ohm resistor in every port as in MCF54455EVB.

The RESET IC has its reset trigger (#MR) through an AND port, which includes among others the manual reset hardware (resistor, capacitor and a button). The connection between the RESET IC and the MCU has been checked, and it’s ok.

Our problem occurs when we soft reset the board using the reset button. It seems to appear specially, but not only, when soft resetting while MCUs initialization. The board simply hangs after reset and doesn’t respond to any of the subsequent resets, just a power down able us to restore the system functionality.

As said before, this problem generally appears when resetting while MCUs initialization. We have tried also an external reset every 10S (time enough for initializating the MCU) and an internal MCU reset after initialization with the same result: the system eventually hangs.

We have been tracking down the reason and we have discovered that the MCU sometimes doesn’t set down completely the SD_CKE signal, just a little bit about 100mV. Surprisingly, at times this is enough to reset the SDRAM, but normally the SDRAM fails to initialize and this hangs the board. 

I have been reading other posts about similar topics and maybe one of them covers the issue we have encountered.:

https://community.freescale.com/message/69918#69918

The problem with this, is that we don't really make a power off sequence, just a reset and then another, so the external oscilator is always powered. And above that, we are suspecting that the SDRAM maybe couldn't be reseated in some states (while writting or reading).

Any ideas?

Thank you.

[TomE]

A quick read of your problem seems to match SECF045 on the MCF5329. Quoting:

Description: If the SD_CKE signal to the SDRAM deasserts while one or more banks are active, theSDRAM enters a clock suspend state. If the SDRAM was driving the data lines before enteringthe clock suspend state, the buffers continue to drive.During a reset, the processor deasserts SD_CKE without any graceful stop period to ensurethat the SDRAM banks are all in an IDLE state. In some cases, the SDRAM could be drivingthe data bus during and immediately after reset. This can lead to possible bus contention whilelatching reset configuration (RCON) values and/or while reading boot code from flash, and thatcould cause the processor to enter an undefined state.

With the affected MCF52xx and MCF53xx chips, the SDRAM, Boot FLASH and RCON config pins were on the same bus. So if the SDRAM jammed its data pins it would corrupt RCON and the boot code. It looks like the MCF5445x has a dedicated SDRAM data bus, so you shouldn't get the same problems.

There's nothing like SECF045 listed for these chips, but it does look like the SDRAM is causing your trouble.

The problem caused by SECF045 is a common one. If you're burst-reading SDRAM and then reset the CPU "uncleanly" (without allowing the SDRAM controller to complete the cycle) then the SDRAM is in the middle of a burst read and is going to deliver the data you're reading on the next few Clock-Enabled Clock Cycles (SD_CLK and SD_CKE) whether you like it or not. There is no "Reset" pin on an SDRAM. The only way to get it back to being sensible is to completely power it off (and short its pins to ground) or to clock it out of its current sequence.

it could be worse. If you were using SDRAM configured the SDRAM in "READ BURST" mode rather than with a fixed burst length, then nothing is going to terminate the reading except for a BURST TERMINATE command, and there's no easy way to issue one of those. It looks like DDR doesn't do this, but you should check the "burst length" in the DDR Mode Register to make sure you're not programming it to "7".

As well, I and others have found that some SDRAM chips need a bit of "exercise" before they can be used. In my case we needed to perform a series of reads and writes to the SDRAM before we could get it to remember anything. Your chips may be getting in some sort of "stuck state" that is preventing them from being initialised properly.

I would suggest that you change your SDRAM initialisation sequence to allow some more time "clocking with SD_CKE" after CKE has been enabled, and you should "exercise" it afterwards. In fact, perform the full SDRAM initialisation twice, that should fix any problems.

Tom

[Kafre]

Thanks for your fast answer TomE.

The thing is that the SD_CKE signal doesn't deasserts (or very slightly). This could be because of the unclean CPU reset.

Anyway, following your instructions we now initialize twice the SDRAM. The MCU still hangs after reset, but - here comes the good part - reponds to new reset signals. This fact allowes us to set a MCU reset supervisor.

I think that my DDR2 ram is not configured in READ BURST mode but my read burst lenght is still 7 as you didn't recommend. I will try to chage this in the near future.

Right now the SDRAM IC change is not an option but I will put it on the table.

Thanks a lot again.

[TomE]

> The thing is that the SD_CKE signal doesn't deasserts (or very slightly).

If the CLK Clock signal stops then the SDRAM remains locked until it is clocked out of this state. There should be a point during initialisation where the clock and CKE are enabled. Put a delay in there rather than immediately proceeding to the next step of initialisation.

> but my read burst lenght is still 7

Where did ThAT come from? I'm talking about the Burst Length configured into the Mode Register in the DDR RAM chip, and not something configured into the DDR Controller.

According to my data sheets, the only allowed burst settings are "0, 1, 2, 3" corresponding to bursts lengths of "1, 2, 4, 8". This should be set to exactly match your CPU's burst length (in units of 16 bits remember). "7" isn't legal.

> The MCU still hangs after reset,

*WHERE* does the CPU hang?

With the MCT5329 problems the CPU can't even start executing code as the SDRAM chip is jamming the same bus it is trying to read its boot code from.

Your CPU should be happily running up until the point where it tries to rely on data stored in the DDR at which point it probably crashes rather than hangs.

Why not code up a short RAM test that runs after it has initialised the DDR? If the test fails it can print something on a console or flash a LED at you. It could even trigger its own reset. It could even go and reinitialise the RAM again, and then keep doing that until it works (or until your external reset controller kicks it again).

Have you tried READING and WRITING some dummy values to the DDR after initialisation and before running? Beware that if you have the data cache on at that point you might not be writing anything to the DDR, so read and write with the data cache off.

Changing the chip brand won't solve anything. it won't guarantee the problem has gone. Reprogramming and resetting twice doesn't guarantee it is working properly either. You can't guarantee the hardware is working properly until you have found exactly what is wrong and have fixed it

Tom

[Kafre]

Hello and thank you again for your fast answer, we have been a little bit busy with other projects so please forgive the delay.

>If the CLK Clock signal stops then the SDRAM remains locked until it is clocked out of this state. There should be a point during initialisation where the clock and CKE are enabled. Put a delay in there rather than immediately proceeding to the next step of initialisation.

This point (I guess) is where we set the SDRAM registers - before the CKE signal activation but after the CK initialization.

        // 5mS Wait Time before raising up CKE        for (i = 0; i < 222; i++) {             _ASM_NOP();         }          sdramc->SDCR = MCF54XX_SDRAMC_SDCR_MODE_EN | MCF54XX_SDRAMC_SDCR_CKE             | MCF54XX_SDRAMC_SDCR_DDR_MODE | MCF54XX_SDRAMC_SDCR_DDR2_MODE            | MCF54XX_SDRAMC_SDCR_ADDR_MUX(1) | MCF54XX_SDRAMC_SDCR_REF_CNT(11)            | MCF54XX_SDRAMC_SDCR_MEM_PS | MCF54XX_SDRAMC_SDCR_IPALL;

In the next image you can see the CK and CKE initialization process.

 

Note: We had some trouble sampling in the 10nS span - we are working at 100Mhz CK speed rate - and had to reduce the sampling frequency. This made our CK signal sampling wrong but the image is useful to calculate the amount of CK cycles before CKE.

Time delayed: 5ms

Cycle Speed Rate: 10nS (100MHz)

Total cycles elapsed: 5mS/10nS =500 000 cycles

This delay should be more than enough to clock out the SDRAM from wherever state it is and avoid the MCU crash.

>Where did ThAT come from? I'm talking about the Burst Length configured into the Mode Register in the DDR RAM chip, and not something configured into the DDR Controller.

>According to my data sheets, the only allowed burst settings are "0, 1, 2, 3" corresponding to bursts lengths of "1, 2, 4, 8". This should be set to exactly match your CPU's burst length (in units of 16 bits remember). "7" isn't legal.

Sorry, my bad. I was talking about SDRAM Controller software values. Our DDR works at a selectable burst length of 4 or 8 (Right now is 8.) But for SDRAM controller configuration (SDCFG2) Burst Length is equal to the chip burst length value (16 bits base) minus one.  I thought you were talking about this.

// BL = Burst Lenght - 1sdramc -> SDCFG2 = MCF54XX_SDRAMC_SDCFG2_BL(7);

>*WHERE* does the CPU hang?

That’s a good question. According to our tests, the CPU hangs when initializing after a reset. More specifically, while attempting to access to the SDRAM but after the SDRAM initialization. This happens mostly if we reset the board while the MCU is accessing to the SDRAM. This means in our case, when coping FLASH software to the SDRAM.

>Your CPU should be happily running up until the point where it tries to rely on data stored in the DDR at which point it probably crashes rather than hangs.

That’s right. Our MCU crashes, and we are unable to restore the normal initialization by using the reset button. We only can only restore it by powering off and on again.

>Why not code up a short RAM test that runs after it has initialised the DDR? If the test fails it can print something on a console or flash a LED at you. It could even trigger its own reset. It could even go and reinitialise the RAM again, and then keep doing that until it works (or until your external reset controller kicks it again).

I see your point. The test could run after the hardware initialization but before the MQX_start call.  But I’m afraid that any access to the SDRAM will crash the MCU, generating a sefl reset infinite loop, as the MCU doesn’t seems able to restore the SDRAM. We will give it a try anyway.

With external reset controller, the only reset signal we can send to the MCU  is the same signal that the reset button generates (they are attached in an AND door) and the MCU only un-crashes after a power on, so it is not very helpful.

>Have you tried READING and WRITING some dummy values to the DDR after initialisation and before running? Beware that if you have the data cache on at that point you might not be writing anything to the DDR, so read and write with the data cache off.

I think is the access to the SDRAM what crashes the MCU. Part of our program runs in the SDRAM, we will check if the crash comes after writing or after the SDRAM jump. Thank you.

>Changing the chip brand won't solve anything. it won't guarantee the problem has gone. Reprogramming and resetting twice doesn't guarantee it is working properly either. You can't guarantee the hardware is working properly until you have found exactly what is wrong and have fixed it

Ok. We will trace this particular error first and determine exactly what is wrong. The double initialization trick didn't work eventually. The only reason why it worked -we think- was the delay added to that particular part of the initialization, but right

now we are not so sure. After adding a big delay we didn’t saw a change in the MCU behaviour, the error persists.

Thanks again.

[TomE]

I said:

>> If the CLK Clock signal stops then the SDRAM remains locked until it is clocked out

>> of this state. There should be a point during initialisation where the clock and CKE

>> are enabled. Put a delay in there rather than immediately proceeding to the next

>> step of initialisation.

Kafre replied:

> This point (I guess) is where we set the SDRAM registers - before the CKE signal activation but after the CK initialization.

> (Code extract showing "5ms delay" followed by CKE enable.

You need the delay *AFTER* CKE has been enabled as well as before. When it thinks it is being burst-read, the DDR chip ignores the clock unless it has CKE asserted as well.

> According to our tests, the CPU hangs when initializing after a reset. More specifically,

> while attempting to access to the SDRAM but after the SDRAM initialization.

My experience is with SDRAM and not DDR.

With SDRAM there's nothing the chip can do that can stall the DRAM controller. When the CPU goes to read or write the SDRAM the controller generates the right cycles and then the CPU will start running again.

DDR is more complicated. The DQS signals are monitored during a data read to know when to read the data. If these are wedged it could lock up the DDR controller. The controller might wait "for ever" for the DQS signals to work, and thereby wedge the CPU as well.

So put a CRO probe onto your DQS signals and see if they're stuck. They should be tri-state, so connect a hugh value resistor (10k) to them and drive that from a mid-level voltage. That lets you distinguish driven-high, driven-low and float conditions on the CRO.

DQS is only meant to be driven from the DDR chips on a READ. So generate a whole lot of WRITES to the RAM chips before attempting any reads. If they're locked up then that might clock them out of whatever state they're in without locking up the DDR controller.

Tom

[Kafre]

Hello again,

We have been running a bunch of tests and we have a few interesting results.

I should comment first that our DDR2 bus working frequency is 100 MHz. This may be important or maybe not, some papers state that the minimum working frequency for a DDR2 bus is 125 MHz, others say that it really doesn't matter if you use a lower frequency. The MCF54452 that we are using works at 200 MHz and has industrial temperature range. The 266 MHz version of the same chip - needed to achieve a higher SDRAM bus frequency - doesn't have industrial temperature range, so changing the MCU is not an option.

TEST 1

For the first test, we made a FLASH/SRAM (internal ram) running application that after hardware initialization, wrote the entire DDR2 and then read each memory position (checking its value). While the MCU was writing or reading we reset the board.

RESULT

The first memory checks were fine. After a few resets, the MCU seemed to write in the DDR2 but when reading it the DDR content wasn't consistent with the one written.  The MCU couldn't restore the SDRAM by doing reset, the SD_CKE signal remained asserted but at a lower level (VTT - 0.1V). Only a power on sequence gets the SD_CKE signal disasserted and the DDR2 answering again with correct data. 

CONCLUSION

The MCU thinks it can, but is unable to write in the DDR; yet it can read the SDRAM. Our former application was loaded from the SDRAM. This means that the processor crashed when trying to execute the application from SDRAM. Looks like the DDR is write locked.

TEST 2

In the second test we returned to our previous program that was loaded from the SDRAM. We did this because it is easier to get the DDR2 locked.  As suggested, we added an additional 5mS delay after the SD_CKE assertion. Thus, the initialization waited 5mS between CK initialization and CKE activation, and 5mS more after CKE activation (with CK running, of course). Like in the former test, we reset the mCU while reading the DDR. We also checked the SD_CKE signal with an oscilloscope.

RESULT

The MCU crashes as normal. The SD_CKE signal sometimes asserts and sometimes not, if the MCU was accessing the SDRAM when resetting, the SD_CKE signal only disasserts a little bit (VTT - 0.1V again) and the MCU crashes in the next initialization; presumably as result of a write DDR2 lock. The SD_CKE signal remains asserted in this low assertion level until power on.

If the MCU wasn't accessing to the SDRAM when the reset happens, sometimes the SD_CKE signal disasserts a little bit  (to VTT – 0.1) and sometimes it dissaserts completely.  This difference doesn't seem to affect the DDR – aka it doesn't lock.

CONCLUSION

The added wait period didn't affect the application. Even after we gave the DDR2 time enough to clock out itself from whatever state it was the MCU still crashes. 

Just in case we checked for Hi-Z values in the SD_CKE port, the voltage values didn't seem consistent with Hi-Z.

TEST 3

For this test we made a few modifications to the initialization software. I'm not going to explain them all, just the one that actually worked: We put the DDR initialization sequence further form the PLL initialization. Even if there was enough time for the PLL to settle down, we weren't really sure. Please excuse my lack of data this was a fast test before fourth test. We removed both 5mS waiting data, and put the SDRAM initialization at the end of our HW initialization (that is not very long indeed). Then we tried to crash the MCU as usual. 

RESULT

The MCU crashed as normal, but we were able to restore the MCU after a second reset. We weren't able to see the SD_CKE but we can assume that the second reset lowered the CKE signal and allowed the system to restart.

CONCLUSION

It seems that the software change affects the SD_CKE signal. It could be a compilation change also, since it had happened before when we tried to initialize twice the sdram.

TEST 4

For the fourth test we physically change the reset circuit. Now, instead of sending a reset signal to the MCU and let the MCU manage the CKE signal, we control the power supply to the SD_VREF signal (1.8V). So every time we reset the circuit, the SDRAM Controller of the MCU and the DDR lost their power, causing a pseudo power on sequence and in theory unlocking them. This has been done with the application given in test 3.

RESULT

The MCU still crashes. However, the power on sequence disasserts the SD_CKE but if the reset was during DDR access, the SD_CKE ends up rising to the higher disassertion level (VREF – 0.1V).

CONCLUSION

The high disassertion level appears to be a symptom of something yet to find, maybe in the SDRAMC or maybe in the DDR. The temperature seems to affect the reset time.

We haven't decided how to proceed yet, but is probable that we drop the DDR2 and pick a DDR for our next prototype.

[TomE]

Have you checked this one, just in case it is related:

https://community.freescale.com/message/53221#53221

> the SD_CKE signal only disasserts a little bit (VTT - 0.1V again)

What is "VTT"? I'm guessing this means SVDref.

> we control the power supply to the SD_VREF signal (1.8V).

SD_VREF has to be half of the DDR supply voltage (SD_VDD). The latter is 2.5V for DDR and 1.8V for DDR2 and Mobile DDR. Did you mean "SD_VDD" here?

> but is probable that we drop the DDR2...

OK, so you're using DDR2 and 1.8V for SD_VDD (and 0.9V for SD_VREF).

SD_CKE is driven by the CPU, by the memory controller. If it isn't at SD_VDD or ground then it is probably tri-state and not driven, which would indicate the DDR controller isn't working somehow, and therefore hasn't been reset properly.

Check the "Supply Voltage Sequencing" section of the Data Sheet, and make sure you're not doing something wrong there.

Note the description in:

3.3.1 Power-Up Sequence
If EVDD/SDVDD are powered up with the IVDD at 0 V, the sense circuits

in the I/O pads cause all pad output drivers connected to the

EVDD/SDVDD to be in a high impedance state.

My experience with the MCF5329 is that the DDR controller is internally POWERED by IVDD. Separately, IVDD is used as an independent input into the pad drivers, which are powered by SD_VDD.

> we control the power supply to the SD_VREF signal (1.8V). So every time we reset

> the circuit, the SDRAM Controller of the MCU and the DDR lost their power, causing

>a pseudo power on sequence and in theory unlocking them.

I don't think that SD_VREF is a power supply for the DDR controller. It is a reference voltage level for the input comparators. Changing it should have no effect on the controller at all. It should be half of SD_VDD too.

Removing SD_VDD shouldn't reset the controller either, as it is most likely to be powered by the core supply IVDD. Only the pad drivers are powered by SD_VDD - that supply shouldn't affect any logic. If you are removing SD_VDD then that is more likely to be resetting the DDR chips themselves rather than resetting any part of the DDR controller.

if you're removing SD_VDD with IVDD still driven, then you may be violating the Power Up Sequence, which allows IVDD to come up LAST, but the graph implies IVDD shouldn't be above SD_VDD or any other supplies.

They're also keen on reminding you:

Use 50 V/millisecond or slower rise time for all supplies.

Here's another interpretation. The full horror of the problems we had with the MCF5329 are coming back to me, details here:

https://community.freescale.com/message/84830#84830

In that chip (and likely in all of them), The CPU RESET signal DOES NOT reset the SDRAM controller! It powers up in a "random state" and has to be clocked out of that state by system clocks. It usually cold-power-ups in a sensible state, but "hot-power-ups" (quick power off and on again) can result in it driving a nasty set of signals at the SDRAM chips which then lock them up, driving the data bus. In the MCF5329 with 32-bit SDR this means the data bus is jammed and the CPU can't read its boot code.

In the MCF5329 case, a workaround is to have a VERY slow rise time on the power supplies so the crystal is running (and clocking the DDR controller into a sane state) before IVDD gets high enough to enable the SDR controller pins.

I think you're seeing problems when resetting the CPU when DDR cycles are running. Search for and read SECF045, basically SD_CKE is de-asserted in the middle of a read and the SDRAM chips keep driving the bus - and then there's no way out of this after reset. In your case this may be happening AND SD_DQS might stop cycling too too. That may be wedging the DDR controller, and it might be failing to be initialised. That might mean the write to the DDR control registers (via SMDR) might not be working either. You could try some high-value resistors (1k perhaps) on SD_DQS connected to SD_CLK as a diagnostic to see if this is related to your problem.

I wouldn't expect changing from DDR2 to DDR to make any difference.

Tom

[TomE]

The next thing you should to is to try and duplicate the problem on the EVB.

If you can demonstrate the failure on that board then Freescale will be able to investigate it much more easily. That was one of the sticking points with the MCF5329 problems that I had. There wasn't much progress until I could demonstrate the problem on the EVB. Things moved rapidly after that.

You should report your problem back to Freescale through "official channels" - through your distributor. You seem to be the first one of this forum with this problem, like I was.

My report to Freescale ended up at 41 pages. By the time I'd gathered enough evidence to write it I'd solved the problem for us. What I was then after was validation of my assumptions and the workarounds we'd discovered - and the errata items to help others. This may be where you end up too.

The MCF53355EVB runs DDR2, so you should stick with that in your design. If you changed to DDR and then tried to demonstrate it, Freescale wouldn't have an equivalent board.

More things to try. have you tried pullups or pulldowns on SD_CKE?

I suspect the DDR2 and the controller are "deadlocked", so I'd suggest first programming the controller in SDR mode, leave it for a while, then disable it and then reprogram it in DDR2 mode. Being in SDR mode might let it recover better than being in DDR2 mode.

Double-check all your SDMR programming. DDR2 needs the Mode Register and multiple Extended Mode Registers loaded - and you have to check the contents with the DDR2 data sheet as well.

.

Tom

[Kafre]

Hello:

Sorry for the late answer, we have been testing all the things we could think about and none of them solved the issue.

Eventually we called Freescale through our local distributor. After explaining the problem, they asked us to run some tests and change some initialization variables - things that we had already tested and a few new - none of them worked. 

We will not have enough time to chase this particular problem in a nearby future so we have decided to assign the software reset  to a power on reset through the Traco Power Vdds we use.  Fortunately It will solve the problem.

Just in case somebody has the same issue, our 100MHz initialization values are:

sdramc->SDCFG1 = MCF54XX_SDRAMC_SDCFG1_SRD2RWP(6)             | MCF54XX_SDRAMC_SDCFG1_SWT2RWP(5) | MCF54XX_SDRAMC_SDCFG1_RD_LAT(3)            | MCF54XX_SDRAMC_SDCFG1_ACT2RW(1) | MCF54XX_SDRAMC_SDCFG1_PRE2ACT(1)             | MCF54XX_SDRAMC_SDCFG1_REF2ACT(6) | MCF54XX_SDRAMC_SDCFG1_WT_LAT(1);            sdramc->SDCFG2 = MCF54XX_SDRAMC_SDCFG2_BRD2RP(5) | MCF54XX_SDRAMC_SDCFG2_BWT2RWP(9)             | MCF54XX_SDRAMC_SDCFG2_BRD2W(6) | MCF54XX_SDRAMC_SDCFG2_BL(7);

Now I will answer your posts:

>Have you checked this one, just in case it is related:

>https://community.freescale.com/message/53221#53221

Seems related indeed, but the changes proposed doesn't work.

>What is "VTT"? I'm guessing this means SVDref.

You are right. I messed up with the names and values of the power ins. I don't even know how you managed to guess what I was talking about, but you were right in your assumptions.

After checking the power up sequence and the rise times, we didn't find anything wrong. Also, the problem only happens when we soft reset the circuit, not in the power on. So we can assume it is not a power problem.

>The CPU RESET signal DOES NOT reset the SDRAM controller! It powers up in a "random state" and has to be clocked out of that state by system clocks.

This issue only happens when resetting while accessing to the DDR. There is no signal of weird state until the jump to the DDR. We tried to demonstrate it was a DDR problem, but we were unsuccessful. According to SECF045 SDRAM keeps running the bus while SD_CKE is desasserted. This could be our case but we can't figure out a walkaround.

>The next thing you should to is to try and duplicate the problem on the EVB.

We weren't unable to replicate the problem on the EVB.We think that the soft reset is different on it.

>I suspect the DDR2 and the controller are "deadlocked", so I'd suggest first programming the controller in SDR mode (..)

Our controller is only programmable as DDR or DDR2 mode. 

>Double-check all your SDMR programming. DDR2 needs the Mode Register and multiple Extended Mode Registers loaded - and you have to check the contents with the DDR2 data sheet as well.

We couldn't fing anything.

Anyway, thank you Tom for your kind answers.