Watchdog Panic Debugging

[SimK]

Hi,

on my STM32MP157C / kirkstone 5.15.145 i'm currently debugging an issue which ends up in a panic handled by OPTEE:

E/TC:0 Panic 'Watchdog' at ?:0

at least i can reproduce it quickly by causing traffic on SPI (connected to a BMA280 ).

...
spi_stm32 44009000.spi: stm32h7_spi_read_rxfifo: 0 bytes left (sr=0000100a)
spi_stm32 44009000.spi: disable controller
spi_stm32 44009000.spi: stm32_spi_can_dma: false
spi_stm32 44009000.spi: stm32_spi_can_dma: false
spi_stm32 44009000.spi: disable controller
spi_stm32 44009000.spi: cpol=0 cpha=0 lsb_first=0 cs_high=0
spi_stm32 44009000.spi: stm32_spi_can_dma: false
spi_stm32 44009000.spi: stm32_spi_can_dma: false
spi_stm32 44009000.spi: stm32_spi_can_dma: false
spi_stm32 44009000.spi: transfer communication mode set to 1
spi_stm32 44009000.spi: data frame of 8-bit, data packet of 1 data frames
spi_stm32 44009000.spi: speed set to 12500000Hz
spi_stm32 44009000.spi: transfer of 1 bytes (1 data frames)
spi_stm32 44009000.spi: dma disabled
spi_stm32 44009000.spi: enable controller
spi_stm32 44009000.spi: stm32h7_spi_write_txfifo: 0 bytes left
spi_stm32 44009000.spi: disable controller
spi_stm32 44009000.spi: stm32_spi_can_dma: false
spi_stm32 44009000.spi: transfer communication mode set to 2
spi_stm32 44009000.spi: data frame of 8-bit, data packet of 4 data frames
spi_stm32 44009000.spi: speed set to 12500000Hz
spi_stm32 44009000.spi: transfer of 6 bytes (6 data frames)
spi_stm32 44009000.spi: dma disabled
spi_stm32 44009000.spi: enable controller
spi_stm32 44009000.spi: stm32h7_spi_read_rxfifo: 2 bytes left (sr=00012002)
E/TC:0 Panic 'Watchdog' at ?:0

I configured to use IWDG2 in NS context:

// kernel DTS and TF-A DTS
&iwdg2{
	status = "okay";

	/* USER CODE BEGIN iwdg2 */
	timeout-sec = <32>;
	/* USER CODE END iwdg2 */
};

Of course it would be perfect to get hints for the SPI issue;-)  But my more generic question is: HOW can we get more details, e.g. a stack trace of the blocking situation. Can i somehow move the handling of the Watchdog into the non-secure context to be able to dump the stack?

[Christophe Guibout]

Hello @SimK,

For this kind of issue, I would recommand to use GDB :  During the SPI use case, at a moment, you will notice that the console is frozen : It means the system is blocked somewhere, so the watchdog is not kicked anymore which will lead to a reboot is less than 32s. During this time, you can start debugging the software with GDB to know where the system is blocked.

BR,

Christophe

[SimK]

Hi,

thanks, i will try to continue as you proposed.

In parallel i'm trying to rollback commits in the kernel because it's perfectly working with our old software based on dunfell / kernel 5.4.192

br, Simon

[SimK]

Hi,

to keep you updated: wasn't necessary to debug.

the last log with SPI verbosity (which was not always on visible) led me to a bug in the ST SPI driver

stm32h7_spi_read_rxfifo: 2 bytes left (sr=00012002)

https://github.com/STMicroelectronics/linux/commit/d6ab414eb4e4ea2dce7b3d34974e752ce6e53099

SR_RXPLVL was not considered which leads to polling until stall detection.

if you also want to use kernel 5.15.145 and have SPI devices connected (which is not that unlikely) - get this patch.