Electrical – Reliability of STM HAL driver For Safety Critical Application

Update: I found the mistake. The SysTick interrupt priority was set to the lowest (15), so calling HAL_Delay() from an ISR with the same or higher priority caused an infinite loop in the HAL_Delay function.

So, take care: If you are using the default HAL settings provided by ST, the priority for SysTick IRQ is set to 15 when calling HAL_Init(). You have to change that in the stm32f7xx_hal_conf.h file or by using the HAL_InitTick(TickPriority) function.

Here is what the HAL documentation of HAL_InitTick says about that issue:

Care must be taken if HAL_Delay() is called from a peripheral ISR process, The the SysTick interrupt must have higher priority (numerically lower) than the peripheral interrupt. Otherwise the caller ISR process will be blocked. The function is declared as __weak to be overwritten in case of other implementation in user file.

I avoid using the JTAG and SWD pins as I/O pins because they need to actively programmed to be I/O pins.

I can't see the code doing that so it is likely that those pins are not operating as GPIO.

Get a copy of 'RM0008 Reference manual' manual from ST.

In section '9.3.5 JTAG/SWD alternate function remapping' it explains how to map the SWD and JTAG pins to become ordinary GPIO pins. Table '37. Debug port mapping' explains which values to set in SWJ _CFG bits in the AFIO+MAPR register to map those JTAG/SWD pins to GPIO.

For example if the SWJ_CFG bits are set to 100, all of the JTAG and SWD pins are available for GPIO.

I would encourage you to avoid this. At least don't map the SWD pins, so that it is easier to debug your board.

Also some of the SWD pins might be accessed from an external debugger (depending on the software driving it) while it is connected, and this might also be a cause of enough activity to light LEDs dimly.