cancel
Showing results for 
Search instead for 
Did you mean: 

NRST connected with NRST_CORE doesn't boot on powerup

Martin Devera
Associate III

We have own MP157 based module and it sometimes hangs after NRST during debug. It doesn't respond to JTAG DAP, further NRST pulses doesn't help but NRST_CORE helps.

It seems as errata "Incorrect reset of glitch-free kernel clock switch". We tried sw workaround (QSPI clk src=per_ck) but it doesn't help.

Thus we tried hw workaround - connect NRST+NRST_CORE (as we use simple smps chip to power core). But the MP1 is stuck in reset - NRST(_CORE) are at GND.

Both VDD (1V8) and VCORE (1V2) are up. Once I disconnect NRST from NRST_CORE (while still powered) it immediatelly boots.

I also scoped the signals - after power is turned on, NRST_CORE goes up, followed by NRST after 10ms. When connected together, they sit at 0 all the time.

Chip revision is 0x2000.

Any idea ?

Thanks, Martin

1 ACCEPTED SOLUTION

Accepted Solutions

Sorry for this very late reply,

regarding your issue, the proposed workaround when using VDD=1.8V without STPMIC1 is to connect NRST to NRST_CORE using a 1nF capacitor (assuming 10nF between NRST and GND and no direct capacitor to GND on NRST_CORE pin). This will provide an NRST_CORE pulse to ensure a correct reset of the internal logic, including debug IPs.

Regards.

In order to give better visibility on the answered topics, please click on 'Accept as Solution' on the reply which solved your issue or answered your question.

View solution in original post

13 REPLIES 13
PatrickF
ST Employee

Hello,

The HW workaround to connect NRST_CORE to NRST should work without issue in your case.

As NRST_CORE is an input only, in any cases it cannot force the NRST_CORE to low when connected together.

If not forced externally by your board circuitry, the only internal reset source which could keep NRST pin to low is VDD voltage.

Please check your VDD supply level according to Datasheet (1.71V minimum). Then check your PCB and HW workaround, you might did connection to the wrong signal.

Regards.

In order to give better visibility on the answered topics, please click on 'Accept as Solution' on the reply which solved your issue or answered your question.
Martin Devera
Associate III

Hello Patrick,

I just tested it on another similar board - it is powered from 3V3 and it works/boots ok when I short both NRSTs. But another one

which is 1V8 powered doesn't start with resets shorted. As soon as I remove the short it boots.

Both designs use the same single 1.2V SMPS enabled by PWR_ON, powered from VDD (1V8 or 3V3). There is difference however,

1V8 has BYPASS_REG1V8=VDD and uses VDD as REG1V8.

Also VDD_3V3USB is unpowered in case of 1V8 design (it is powered later by firmware). Remainder of design is the same, also

PCB is the same (only some components changed as needed).

VDD is measured 1.85V. PDR_ON* are connected to VDD.

I can see the NRST_CORE is kept low by NRST pin.

Because it hangs only when resets are shorted, there must be some way how NRST_CORE low prevents NRST releasing its pad..

Martin

Hello,

did you check that VDD_ANA is correctly connected to VDD (as well as VSS_ANA to VSS) ?

which STM32MP1 reference are you using ?

Is you PCB allow to have a try with PDR_ON to VDD ?

Is it possible to have a look to your schematics (by private message if you prefer) ?

Regards.

In order to give better visibility on the answered topics, please click on 'Accept as Solution' on the reply which solved your issue or answered your question.
Martin Devera
Associate III

Hello,

vdd_ana is star connected to vdd, however vdd_a is unpowered at the boot time.

PDR_ON is at VDD. However I have resisors there so that I could try to GND them.

I'm attaching module schematic, at bottom of the last page there are resistors and key

to 1V8 vs 3V3 difference.

The 3V3 module is tested by connecting (conn J1) all module VDD_X pins directly to 3V3.

1V8 version is connected: VDD_STM=VBAT=1V8 permanent, +3V3 (J1.69) at 0V at time

of booting (powered later by gpio).

I can PM you these motherboard schematics too if needed (these are a bit larger).

When connecting NRST_CORE to NRST I removed C14.

Thanks, Martin

Please double check if any unpowered board component could tie NRST low. This is a common pitfall (i.e. when a component has no supply, generally there is protection diodes on inputs who give a current path to 0V). In that case you need a schottky diode in serie to avoid any low level on a board peripheral to propagate to STM32MP1 NRST pin.

You usually detect that by looking for intermediate NRST levels which are not really 0V, but some hundred of mV.

Maybe this is also the case on your 3.3V platform, but as NRST input threshold is higher than with VDD=1.8V, it might barely works.

In order to give better visibility on the answered topics, please click on 'Accept as Solution' on the reply which solved your issue or answered your question.
Martin Devera
Associate III

Patrick,

there is no other component on NRST net (except capacitor). I just checked for sure. It is also evident from the fact that when I disconnect NRST_CORE from

NRST net, everything works. NRST level is 6mV.

Se attached DSO images. Yellow is 1V8, blue 1V2 and magenta NRST.

Here it is when NRST_CORE is unconnected:

0693W000001qoe4QAA.png

Now, lets connect NRST_CORE to NRST:

0693W000001qoexQAA.png

You can see, PWR_ON is eaxctly the same, only NRST stays low. Let's try to prove NRST_CORE forces NRST N-fet to be on.

I connected 1uF to NRST_CORE, thus delay its release by approx 20ms, blue line is NRST_CORE:

0693W000001qog5QAA.pngYou can see that NRST release is now delayed to time when NRST_CORE reaches 1.1V. One could draw conclusion that when

VDD is 1V8 (as opoosed to 3V3) NRST is held low when NRST_CORE is low.. Which would explain why interconnecting them never

boots. But it is only hypothesis yet.

Martin

PatrickF
ST Employee

Could you please provide information of the device you use (especially revision and manufacturing date). From your schematics I see it is a TFBGA361 - 12x12 package.

In order to give better visibility on the answered topics, please click on 'Accept as Solution' on the reply which solved your issue or answered your question.
Martin Devera
Associate III

I attached the chip image. Both chips are the same. Also relevant revision data:

0x5c005240: 135685e1

0x50081000: 20006500

0693W000001qqPpQAI.jpg

PatrickF
ST Employee

Hello,

seems you have pointed out a weakness on the proposed workaround when used with VDD=1.8V. We are still doing investigations.

Another valid workaround is to implement the AN5256 section "Crash recovery management" to control VDDCORE instead of directly use PWR_ON.

This PWR_ONRST signal might already exist in your design to control boot Flash supply, as described in the AN.

In that case, the connection between NRST_CORE and NRST is not needed anymore (as VDDCORE will be power cycled, we rely on STM32MP1 internal reset circuitry instead of using NRST_CORE).

Note that you need to program RCC_RDLSICR.RPCTL field to ensure supplies have time to fall to 0V (or close to), e.g. in case of watchdog reset.

In order to give better visibility on the answered topics, please click on 'Accept as Solution' on the reply which solved your issue or answered your question.