NRST connected with NRST_CORE doesn't boot on powerup

[Martin Devera]

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

[PatrickF]

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.

[Martin Devera]

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

[PatrickF]

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.

[Martin Devera]

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

[PatrickF]

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.

[Martin Devera]

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:

Now, lets connect NRST_CORE to NRST:

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:

You 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]

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.

[Martin Devera]

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

0x5c005240: 135685e1

0x50081000: 20006500

[PatrickF]

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.

[PatrickF]

I have to apologize, but my proposal above is probably also not valid for VDD=1.8V. For the moment, there is no solution to implement the workaround you mention with VDD=1.8V. We are still investigating. But your issue of freeze during debug is maybe not linked to the bug (which is linked to a potential risk of freeze in case of NRST).

[Martin Devera]

Thank you for the information. To solve the issue we just added STM8 to the SOM which takes care of all resets and power sequencing. I'm interested in your note above regarding debug freeze source. Have you some idea how to spot the reason ?

I have seen it only when boot pins select flash boot. Never in engineering boot (yet). CPU always consumes 40ma from 1V8 or 30mA from 3V3 in such state.

I just booted linux (1V8 version) and pulsed NRST. This time it hangs. JTAG itself works but cant access CA7:

> reset
JTAG tap: stm32mp15x.tap tap/device found: 0x6ba00477 (mfg: 0x23b (ARM Ltd.), part: 0xba00, ver: 0x6)
JTAG tap: stm32mp15x.clc.tap tap/device found: 0x06500041 (mfg: 0x020 (STMicroelectronics), part: 0x6500, ver: 0x0)
Deferring arp_examine of stm32mp15x.cpu2
Use arp_examine command to examine it manually!
Deferring arp_examine of stm32mp15x.ap2
Use arp_examine command to examine it manually!
> halt
timeout waiting for DSCR bit change
Error waiting for halt

But generic access to DAP bus works (see DBG ROM table readout):

> stm32mp15x.ap1 mdw 0xe0080000 10 
0xe0080000: 00001002 00002003 00003003 00010003 00020003 00040002 00050003 00051003 
0xe0080020: 00052003 00053003

And AXI bus seems to be stuck:

> stm32mp15x.axi mdw 0x50000004 
0x50000004: 00000000

Pulse on NRST_CORE solves the issue. Any idea how to debug this state ?

[PatrickF]

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.

[Martin Devera]

Hi Patrick, thank you for the information. We solved it in meantime by adding extra STM8L MPU to our SOM which handles NRST/NRST_CORE.

It pulses NRST_CORE only when there is no "ACK" from bootloader in some time.

It allows us to use JTAG over bootloader (which NRST-NRST_CORE interconnect prevents). Also we used the oportunity to handle BOOTn pins

so that we can force engineering boot from debugger (without jumpers nor soldering iron).

Regards, Martin