MP1 SWD access probably tristates all GPIO sometimes

[Martin Devera]

I'm testing STM32MP157A for our new projects. The MPU VCC is 1V8, USB is 3V3. Debugger is connected to two SWD pins. One of first test is:

• boot into DFU loader, upload simple code to 0x2ffc2500:

S_GPIO_ALT(GPIOA,13,2);
S_GPIO_ALT(GPIOA,14,2);
RCC->MCO1CFGR = 0x10f0;
RCC->MCO2CFGR = 0x10f0;
for (;;);

• S_* are obvious macros setting MODER and ALT registers
• the code is uploaded by dfu-util -d 0483:df11 -a 1 -D boot_test.stm32

So far so good, code is started, I can see 4 and 25MHz at PA13/14.

in openocd I did:

> bp 0x2ffc25e0 4 hw
breakpoint set at 0x2ffc25e0
 
stm32mp15x.cpu0 rev 5, partnum c07, arch f, variant 0, implementor 41
stm32mp15x.cpu0: MPIDR level2 0, cluster 0, core 0, multi core, no SMT
target halted in ARM state due to breakpoint, current mode: Supervisor
cpsr: 0x400001d3 pc: 0x2ffc25e0
MMU: disabled, D-Cache: disabled, I-Cache: disabled

It seems ok. I tested AXI access, confirmed that I'm in TZ secure state, can read even ROM firmware.

Openocd polls MP1 every 100ms by 2 SWD register reads (blue), MCOs are stable (yellow):

Ok, I reset, reupluad code, all the same way, but now, no breakpoint, let's use halt:

> halt
stm32mp15x.cpu0 rev 5, partnum c07, arch f, variant 0, implementor 41
target halted in ARM state due to debug-request, current mode: Supervisor
cpsr: 0x400001d3 pc: 0x2ffc25e0
MMU: disabled, D-Cache: disabled, I-Cache: disabled

It seems the same as before (it should). But wait, what is this:

MCO outputs are no longer there, when MPU is in halt ! Even more interesting is,

outputs are on every 100ms - each SWD register read turns GPIOs back on for a while but then they are off again.

What I tested:

• other GPIO (PA8) because PA13/14 are a bit special (DBG outputs possible as AF0)
• plain GPIO output, when I send "1" it sometimes goes to 0 or Z
• resume of MPU makes it ok
• reading of GPIO regs reveals that its programing have not changed
• using JTAG instead of SWD solves it too

It seems as if there is another asynchronous signal in the SoC which can manipulate GPIOs

and SWD somehow affects it.

The behavior is strange and we'd like to find what causes it, before we decide on this SoC.

Thanks, Martin

[Bernard PUEL]

Hello Martin,

we could not reproduce the issue with ST deliverable and we are suspecting issue with openocd version you are using.

Openocd version (and patches) compatible with ST delivery can be found here: https://github.com/STMicroelectronics/meta-st-stm32mp/tree/thud/recipes-devtools/openocd

This is Yocto recipe but you can easily find the version reference and the 5 patches to apply on it. This will add also the support of ST link that is the easiest simple way to debug on ST ref boards.

The official OpenOCD does not support (yet) STM32MP1 nor the ST-Link extension for Cortex-A

To allow us to replicate this use case, would you please share:

• what version of OpenOCD you are using (e.g. the git hash of the commit you have checkout). Did you applied any patch on top ?
• the OpenOCD configuration script
• which JTAG/SWD probe you are using
• which board and switch configuration

[Martin Devera]

Hello Bernard,

thanks for the reply. I was waiting for DK2 board to arrive so that I can retest it on it. I've done it just now, but the "bug" is somehow gone now...

I'm not sure, but I probably updated Openocd in meantime (I regularly compile from GIT tree because I often add new drivers/patches).

Just now it works with both of my adapter (FTDI based in-house one) and with stlink-dap.

I'll return if I can manage to trigger it.

Just now I have to make LPDDR2 work. BTW, can I take oportunity and ask why LPDDR2 is in RM marker as unsupported in 0.8 pitch packages ?

It is weird ...

Martin

[PatrickF]

For system point of view, it does not make sense to put LPDDR2/3 which are only available on pitch 0.5mm or below with STM32MP1 using pitch 0.8mm which target lower cost PCB.

Anyway, there is no blocking mechanism using LPDDR2/3 with 0.8mm packages, but signal integrity analysis was not done with LPDDR2/3 on these packages, and they are not supported by CubeMX nor supported by layout examples.

[Martin Devera]

Hello Patrick,

thanks for the reply. I'm glad to hear there is no technical obstacle except SI. Well it still makes sense (AFAIK) because LPDDR2 is 0.65 ball pitch

and has strategic spaces to allow routing without via between balls (can be done on 4mil, 4layer no VIP). However 0.5mm pitch MP1 can't

be done without VIP, can be ?

The main reason is consumption in mobile device. DDR3L AC/ODT termination is power hungry. We can try to go without terminations

or use serial terms but we need to measure overshots then to be on safe side.

BTW, ref. manual talks about DCU unit in PUBL, it is in u-boot headers too but no register description. I found some clues from Synopsys pdf, but IP parameters are missing (as command cache size e.g.). Is it planned to document it ? It is nice interface to debug DDR SI..