Tagged: openocd flash
May 16, 2020 at 23:17 #28139
I’m trying to setup a STM32H750B-DK BSP demo project for the STM32H750 Discovery board.
I have build a QSPI driver as described in this tutorial
and successfully tested the driver as described.
I’m also using a bootloader (based on ExtMem_Boot in the BSP) which is burned into the STM internal flash. This then jumps to the demo application which is loaded in QSPI flash. When I tried to launch the demo app in VisualGDB, it was hanging somewhere in the flash driver by the look of the debug output
Debug: 1053 2974 target.c:1626 target_call_event_callbacks(): target event 16 (debug-resumed) for core stm32h7x.cpu0
Debug: 1054 2974 target.c:1626 target_call_event_callbacks(): target event 4 (resume-end) for core stm32h7x.cpu0
Debug: 1055 2975 target.c:3048 target_wait_state(): waiting for target halted...
Error: 1057 3976 target.c:3056 target_wait_state(): timed out while waiting for target halted
Debug: 1058 3976 hla_target.c:573 adapter_halt(): adapter_halt
Debug: 1059 3976 target.c:3048 target_wait_state(): waiting for target halted...
Debug: 1060 4477 log.c:417 keep_alive(): keep_alive() was not invoked in the 1000ms timelimit (1001). This may cause trouble with GDB connections.
Error: 1062 4477 target.c:3056 target_wait_state(): timed out while waiting for target halted
Debug: 1063 4477 cortex_m.c:1399 cortex_m_unset_breakpoint(): BPID: 3, Type: 1, Address: 0x24003c2c Length: 2 (set=1)
Debug: 1064 4477 hla_target.c:772 adapter_write_memory(): adapter_write_memory 0x24003c2c 2 1
Debug: 1065 4479 stlink_usb.c:559 stlink_usb_error_check(): wait status SWD_DP_WAIT (0x14)
Debug: 1066 4481 stlink_usb.c:556 stlink_usb_error_check(): wait status SWD_AP_WAIT (0x10)
Debug: 1067 4484 stlink_usb.c:556 stlink_usb_error_check(): wait status SWD_AP_WAIT (0x10)
Debug: 1068 4489 stlink_usb.c:556 stlink_usb_error_check(): wait status SWD_AP_WAIT (0x10)
So, I followed this (excellent!) tutorial and debugged openocd to see where the problem was occurring
I tracked it down to this call
which would ultimately fail waiting for the call to finish (wait_algorithm)
In the QSPIDriver, the FLASHPlugin_Unload() functions looks like this
SysTick->CTRL &= ~SysTick_CTRL_ENABLE_Msk;
for (int i = 0; i < sizeof(NVIC->ICER) / sizeof(NVIC->ICER); i++)
NVIC->ICER = -1;
If I disable the call to HAL_DeInit() and rebuild the driver, then my demo project launches without error.
My question is why ? What could be happening in the deinit to cause it to fail to hit the breakpoint openocd places ?
Interestingly, if I just reset the board it starts up fine, running through the bootloader and into the main app, so I’ll leave the call disabled for now, just curious why that would be ?May 16, 2020 at 23:45 #28140
It’s hard to say why HAL_DeInit() would hang on a specific board, however it should be relatively easy to find out by terminating the OpenOCD instance and then attaching to the device as shown in this tutorial. It will show what exactly is happening on the device when it hangs.May 17, 2020 at 05:13 #28142
This issue gave me a lot grief too. It’s actually a defect in the Hal. I logged a bug report quite a while ago, but I haven’t heard anything about a fix. It happens when it de-initialises the clock, the macro changes some reserved bits in the register. You can view the bug here:
So my workaround is in stm32h7xx_hal_rcc.h:
changeC++1#define __HAL_RCC_AHB3_FORCE_RESET() (RCC->AHB3RSTR = 0xFFFFFFFFU)
with thisC++123456789#define __HAL_RCC_AHB3_RESET_ALL (RCC_AHB3RSTR_MDMARST | \RCC_AHB3RSTR_DMA2DRST | \RCC_AHB3RSTR_JPGDECRST | \RCC_AHB3RSTR_FMCRST | \RCC_AHB3RSTR_QSPIRST | \RCC_AHB3RSTR_SDMMC1RST)#define __HAL_RCC_AHB3_FORCE_RESET() (RCC->AHB3RSTR = __HAL_RCC_AHB3_RESET_ALL)
You must be logged in to reply to this topic.