Debug on STM32MP1 issue

romain2 · ‎2020-03-06

Hi,

We are currently developing on the STM32MP1. Our goal now is to be able to debug the core at the different running stages : TF-A, Optee, U-boot and kernel. We are using the DK2 with a ST-link and openOCD.

When using your Setup.gdb we experience some issue during the debug session :

We can't use the step instruction but we can use the stepi instruction. When we use the step instruction we have the following error on openOCD :

Error: Timeout waiting for cortex_a_exec_opcode
Error: Timeout waiting for InstrCompl=1
Error: Timeout waiting for dpm prepare
Error: Timeout waiting for cortex_a_exec_opcode
Error: can't add breakpoint: unknown reason
Warn : negative acknowledgment, but no packet pending
Warn : negative acknowledgment, but no packet pending

The exact same error message is found when loading u-boot symbol after gdb is connected to openOCD.
The software breakpoint doesn't work, only the hardware breakpoints break the core.

We also have some questions regarding this debug script :

What is the purpose of these lines :

monitor cortex_a smp_gdb 0
stepi
monitor cortex_a smp_gdb -1
# No SMP, only core 0 for the moment. We'll re-enable it in kernel
monitor cortex_a smp_off

We understand what it does, but we don't understand why it is needed.

Furthermore, in the following snippet :

monitor reset
monitor sleep 2000
monitor reset halt

Why is this sequence is needed ? Why not use directly the monitor reset halt ?

Thanks for you answer,

Regards,

Romain

AntonioST · ‎2020-03-11

It is important to load the symbols in advance, before GDB halts in the code reference by the symbols.

Also, symbols should be loaded before command "target remote ..." because GDB automatically halts the target at connect.

The reason is that GDB loads from the ELF file, together with the symbols, the ABI model. If GDB doesn't know the ABI in use, it will try to "guess" the stack frame by executing several memory read at addresses contained in r11 (potentially used as fp) and in the stack. Often such addresses point to uninitalized busses/peripherals with consequent read abort or bus hang.

Can you please explain better how to replicate the issue with step, not present with stepi? And also regarding SW breakpoints?

The first sequence you ask for, is used to guarantee GDB is connected to the first core, the only one that is running at boot. The sequence is not well documented in http://openocd.org/doc/html/Architecture-and-Core-Commands.html

The meaning is:

1) monitor cortex_a smp_gdb 0 : ask OpenOCD to switch to core 0

2) stepi : fake stepi. Due to command 1) OpenOCD will only switch core and return to GDB the state of core 0

3) monitor cortex_a smp_gdb -1 : return to normal mode, while core 0 remains set as default

5) stop using SMP. From now on only core 0 would be connected to GDB

The second sequence is used to guarantee the halt at soon as possible.

1) reset the board and let the boot code to initialize the PMIC

2) just wait a little

3) now reset halt the cores

After these lines there are also:

4) monitor gdb_sync

5) stepi

these last are required to synchronize GDB to the state of the target after reset. GDB does not know anything about resetting the target. The "monitor" commands are unknown by GDB and simply forwarded to OpenOCD.

The steps 4 and 5 are used to create a fake stepi that force GDB to reload the state of the target after the reset

View solution in original post

AntonioST · ‎2020-03-11