2020-06-12 09:48 AM - last edited on 2023-06-16 09:33 AM by Kevin HUBER
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
Solved! Go to Solution.
2020-06-19 02:13 AM
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).
2020-06-19 02:36 AM
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 ?
2021-01-06 01:24 AM
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.
2021-01-06 08:08 AM
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