STM32 resetting on first sdram access

[Fabrizio Pizzolato]

Posted on August 29, 2017 at 10:09

Good morning, I have a STM32F429 based board, the MCU is interfacing a Micron SDRAM (MT48LC4M32B2). We successfully configured the sdram interface using the FMC driver. We use 1.4.3 version.

We had a first production round where about half of the boards have the following problem: on the very first access to the sdram the MCU hard resets. I could verify that a 1ms negative pulse is present on the MCU reset line. After this reset the application restarts and access to the SDRAM is executed with no problems. 

Note: by saying first access I mean the first time the memory is used. I always configure it (by using low level functions from the driver) without problems. At a later time (actually through an external command) I create a pointer to the first memory location in sdram and try to use it, and this is when the problem occurs.

Anybody here had similar problems? Any ideas on how to identify the problem?

thank you very much

[waclawek.jan]

Posted on August 29, 2017 at 10:37

Inadequate power supply/grounding/decoupling, and memory having an increased consumption when it first time accesses the memory array?

JW

[Fabrizio Pizzolato]

Posted on August 29, 2017 at 10:48

I monitored the MCU supply and it is stable during the reset pulse. Consumption, anyway, is about 50 mA and does not increase when the problem shows.

[Tesla DeLorean]

Posted on August 29, 2017 at 12:15

No defined mechanism to generate a reset from such an access. Do you have a watch dog timer? Pull up on NRST, other circuitry?

Not much to work with here.

Anyone one from ST review circuit or PCB design?

[Fabrizio Pizzolato]

Posted on August 29, 2017 at 14:57

No watch dog timer active and I removed a couple of lines that coupled electrically NRST to other arts of the circuit.

So it seems indeed an electrical problem, unless anybody can suggest something else to verify.

[waclawek.jan]

Posted on August 29, 2017 at 15:17

Let me reiterate the power supply problem idea: what exactly is the VDDA/VDDA voltage with regard to VSS/VSSA? What is its primary source? Is this same source used to power the SDRAM? Have you observed it with an oscilloscope, both GND and probe pin directly on the mcu pins, synced to the critical moment?  Is PVD and/or BOR enabled; in the latter case what is the BOR level? What are the VOS settings? What is the clock and FLASH latency setting? Does the problem occur if you set the clock to some other source, e.g. HSI? Do you have some sort of (hard- or any other-) fault handlers in place?

JW

[AVI-crak]

Posted on August 29, 2017 at 15:38

Initialize the contact connections to the memory in two stages:

1) address lines + control, reset sdram memory.2) data lines, ending settings and clearing memory.The MT48LCxxx may be in sleep mode immediately after the reset, this is an undefined state. But a quick reset can cause a current consumption pulse. The documentation specifies the time and sequence of initialization of the MT48LCxxx, you can not delay and you must not rush. If you put more ceramics - then you can act on the break.

By the way, the sleep mode is a cool thing.

[Tesla DeLorean]

Posted on August 29, 2017 at 15:28

Voltage and caps at VCAP1/2 pins would be things to double check. But honestly not sure why SDRAM should trigger.

Would have built a SDRAM memory tester for prototypes, and saturate test those, and 'working' boards from batch.

[Fabrizio Pizzolato]

Posted on August 29, 2017 at 16:41

Supply is as follows: a regulator gives 3,5 Volts to both devices; an inductance is used to get this to the MCU, while the sdram receives its supply through a MOS. Observing both at the moment of the reset, supply of the MCU is stable before the event (some disturbs are observed after the event, probably due to peripheral switching off after the MCU resets); same for the SDRAM supply (which drops after the event because the enable MOS is switched off once the MCU resets). PVD and BOR are not configured. I cannot answer for other settings (I have inherited the project and still need some time to find all configurations). I however verified that none of the fault handlers present are hit when the reset occurs: it seems it is not originated by the mcu but by some external trigger.

[Fabrizio Pizzolato]

Posted on August 29, 2017 at 16:58

I had some doubts on this one. I actually tried to follow step by step what's on the 'Initialization' chapter, with two problems.

1. I have a 1ms tick on the system, so some of the instructions can't be accurately replied.

2. also using FMC driver some commands are not available at the driver level: in stm32f4xx_ll_fmc.h see 'FMC_SDRAM_CMD...' defines.

So for example when the datasheets states, for example 'Starting at some point during this 100μs period, bring CKE HIGH. Continuing at least through the end of this period, 1 or more COMMAND INHIBIT or NOP commands must be applied' I can't be sure on what to do.