Target reset is less reliable on testing branch

[hyves42]

• [x] I made serious effort to avoid creating duplicate or nearly similar issue

In order to allow developers to isolate and target your respective issue, please take some time to select the check boxes below and fill out each of the following items appropriate to your specific problem.

• [x] Programmer/board type: [STLINK V2 and V3] connected to target board via SWD connector
• [x] Operating system an version: [ubuntu] (e.g Linux, Windows)
• [x] stlink tools version and/or git commit hash: [Testing 32ce4bf88a816fb6a9841a33e6c5f6b593a9b927]
• [x] stlink commandline tool name: [st-flash]

I noticed a regression between st-flash 1.7.0 from ubuntu repos and the current testing branch

I generally reset the target board with the following command:

$ st-flash reset

Expected/description: The target resets (OK on v1.7.0)

This does not work anymore on the testing branch, the target does not reset.

Interestingly enough, nucleo boards still reset fine, I only see issues when I connect an external board via stlink.

Investigations:

I found a way to fix it but I don't know enough about stlink internals to see if it's a good solution.

The changes since 1.7.0 relevant to this issue are:

• stlink_reset() now sets sl->core_stat = TARGET_RESET;
• stlink_exit_debug_mode() now checks

  if (sl->flash_type != STM32_FLASH_TYPE_UNKNOWN  &&
    sl->core_stat != TARGET_RESET ) {
  // stop debugging if the target has been identified
  stlink_write_debug32(sl, STLINK_REG_DHCSR, STLINK_REG_DHCSR_DBGKEY);
  }

  If I remove the test on sl->core_stat != TARGET_RESET, the reset command starts working again. But this test was probably added for a valid reason so I will leave devs with more expertise find the right solution.

[hyves42]

I tried to investigate this issue again today. It was actually not that easy to reproduce, and it finally happened after I reflashed the stm32 with stlink-gui 1.7.0.

After that, no matter how many times I unplugged or rebooted my setup, I was not able to perform any successful reset with st-flash reset from testing branch. The fix suggested above in stlink_exit_debug_mode() still works.

I can see a pulse on nRST in both cases so I guess the reset is actually performed, but maybe the processor is left in a not running state ?

[salyzyn]

JAFO here with some thoughts:

• The fact that nRST is pulsed seems curious and yet not causing a target reset. I have had a similar issue with nRST with targets that did not pull down the internal Boot0 line. The not running state is probably a DFU state, or running out of RAM state depending on the Boot1 status. A floating Boot0 line will randomly chose for you.
• It should be noted that most STLink/v2 cheap clone boards do not have the target nRST correctly connected. They are connected to the on-programmer's host nRST line, not the GPIO output that the host was meant to toggle on the target. Good on ya.

Summary: please check the target Boot0 line for pull down to be sure the external board is not the cause.

[hyves42]

Boot0 is indeed tied to ground on the external board. I'm using both an STM32-V3-SET and some nucleo boards as STlink V2. Also I had no issue before with version 1.7.0 or with official ST tools so I don't think it is an hardware issue.

Tested again today, as long as I'm not unplugging anything randomly and not exiting stlink-gui before disconnecting I have no issue with board reset so I changed the title of this issue to something less alarming.

But still, version 1.7.0 can handle reset in cases where the system state is unclear better than the testing branch.

[Nightwalker-87]

@hyves42: Please have a look at #1260 as well. Maybe this can give some further hints.

[Nightwalker-87]

Can someone with the respective hardware and knowledge please help to debug this?

[Ant-ON]

@Nightwalker-87 After a software reset, the core remains in the Halt state. After the reset, you must run the core so that the firmware can start...

[Nightwalker-87]

... which does not sound like a bug to me really. I think to have read this in an earlier ticket targeting this topic.

[Ant-ON]

@Nightwalker-87 But this is not the user expected behavior... @hyves42 Try to change reset code in the src/st-flash/flash.c file:

        // reset
        if (stlink_reset(sl, RESET_AUTO)) {
            printf("Failed to reset device\n");
            goto on_error;
        } 

to

        // reset
        if (stlink_reset(sl, RESET_AUTO)) {
            printf("Failed to reset device\n");
            goto on_error;
        } else
            stlink_run(sl, RUN_NORMAL);