openocd flash plugin hangs in loaded_plugin_unload

Sysprogs forums Forums VisualGDB openocd flash plugin hangs in loaded_plugin_unload

Tagged: 

This topic contains 2 replies, has 3 voices, and was last updated by  davidoz 1 week, 1 day ago.

Viewing 3 posts - 1 through 3 (of 3 total)
  • Author
    Posts
  • #28139

    Rob Belcham
    Participant

    I’m trying to setup a STM32H750B-DK BSP demo project for the STM32H750 Discovery board.

    https://github.com/STMicroelectronics/STM32CubeH7/tree/master/Projects/STM32H750B-DK

    I have build a QSPI driver as described in this tutorial

    https://visualgdb.com/tutorials/arm/stm32/flash/

    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

    https://visualgdb.com/tutorials/arm/openocd/build/

    I tracked it down to this call

    loaded_plugin_unload(&loaded_plugin, plugin_info->FLASHPlugin_Unload);

    which would ultimately fail waiting for the call to finish (wait_algorithm)

    In the QSPIDriver, the FLASHPlugin_Unload() functions looks like this

    int FLASHPlugin_Unload()
    {
    BSP_QSPI_DeInit(0);
    HAL_DeInit();
    SysTick->CTRL &= ~SysTick_CTRL_ENABLE_Msk;

    for (int i = 0; i < sizeof(NVIC->ICER) / sizeof(NVIC->ICER[0]); i++)
    NVIC->ICER[0] = -1;

    return 0;
    }

    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 ?

    #28140

    support
    Keymaster

    Hi,

    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.

    #28142

    davidoz
    Participant

    Hi,

    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:

    https://github.com/STMicroelectronics/STM32CubeH7/issues/19

    So my workaround is in stm32h7xx_hal_rcc.h:

    change

    with this

Viewing 3 posts - 1 through 3 (of 3 total)

You must be logged in to reply to this topic.