search

stlink-org / stlink

Open source STM32 MCU programming toolset
BSD 3-Clause "New" or "Revised" License
4.35k stars 1.23k forks source link

[STM32G031]: can't connect to target: unknown chip id (--connect-under-reset not working) #1098

Closed pm-daniel closed 1 year ago

pm-daniel commented 3 years ago

Commandline-Output:

st-flash --connect-under-reset --debug erase
st-flash 1.6.1
2021-03-10T13:43:30 DEBUG common.c: *** looking up stlink version
2021-03-10T13:43:30 DEBUG common.c: st vid         = 0x0483 (expect 0x0483)
2021-03-10T13:43:30 DEBUG common.c: stlink pid     = 0x374e
2021-03-10T13:43:30 DEBUG common.c: stlink version = 0x3
2021-03-10T13:43:30 DEBUG common.c: jtag version   = 0x7
2021-03-10T13:43:30 DEBUG common.c: swim version   = 0x0
2021-03-10T13:43:30 DEBUG common.c:     notice: the firmware doesn't support a swim interface
2021-03-10T13:43:30 DEBUG common.c: *** looking up stlink version
2021-03-10T13:43:30 DEBUG common.c: st vid         = 0x0483 (expect 0x0483)
2021-03-10T13:43:30 DEBUG common.c: stlink pid     = 0x374e
2021-03-10T13:43:30 DEBUG common.c: stlink version = 0x3
2021-03-10T13:43:30 DEBUG common.c: jtag version   = 0x7
2021-03-10T13:43:30 DEBUG common.c: swim version   = 0x0
2021-03-10T13:43:30 DEBUG common.c:     notice: the firmware doesn't support a swim interface
2021-03-10T13:43:30 DEBUG common.c: stlink current mode: mass
2021-03-10T13:43:30 DEBUG usb.c: JTAG/SWD freq set to 0
2021-03-10T13:43:30 DEBUG common.c: *** set_swdclk ***
2021-03-10T13:43:30 INFO usb.c: Unable to match requested speed 1800 kHz, using 1000 kHz
2021-03-10T13:43:30 DEBUG common.c: stlink current mode: mass
2021-03-10T13:43:30 DEBUG common.c: *** stlink_enter_swd_mode ***
2021-03-10T13:43:30 DEBUG common.c: *** stlink_jtag_reset ***
2021-03-10T13:43:30 DEBUG common.c: *** stlink_reset ***
2021-03-10T13:43:30 DEBUG common.c: *** stlink_write_debug32 5fa0004 to 0xe000ed0c
2021-03-10T13:43:30 DEBUG common.c: Loading device parameters....
2021-03-10T13:43:30 DEBUG common.c: *** stlink_core_id ***
2021-03-10T13:43:30 DEBUG common.c: core_id = 0x000003e8
2021-03-10T13:43:30 DEBUG common.c: *** stlink_read_debug32 3e8 is 0xe0042000
2021-03-10T13:43:30 WARN common.c: unknown chip id! 0x3e8
Failed to connect to target

Expected/description: my board uses swd and swclk gpios, so in order to connect with mcu stlink must connect under reset conditions, while it works perfectly fine using STM32CubeProgrammer (connect under reset option is selected), st-flash fails to read chip id It looks like --connect-under-reset param doesn't have any effect. At the same time, I can use the same st-flash config to program all my other boards.

STM32CubeProgrammer log:

13:57:38 : ST-LINK SN : 001A003E3137511433333639
13:57:38 : ST-LINK FW : V3J7M2
13:57:38 : Voltage : 3.33V
13:57:38 : SWD freq : 24000 KHz
13:57:38 : Connect mode: Under Reset
13:57:38 : Reset mode : Software reset
13:57:38 : Device ID : 0x466
13:57:38 : UPLOADING OPTION BYTES DATA ...
13:57:38 : Bank : 0x00
13:57:38 : Address : 0x40022020
13:57:38 : Size : 32 Bytes
13:57:38 : Bank : 0x01
13:57:38 : Address : 0x40022080
13:57:38 : Size : 16 Bytes
13:57:38 : UPLOADING ...
13:57:38 : Size : 1024 Bytes
13:57:38 : Address : 0x8000000
13:57:38 : Read progress:
13:57:38 : Data read successfully
13:57:38 : Time elapsed during the read operation is: 00:00:00.001
kwarek commented 3 years ago

Hello, I'm using stm32g030j6 (8-pin soic), so i've had the same problem. I've managed to get it to work with attached patch. There is also a separate problem, chip id is read as 0xE5C. I've just added new STM32_G0 variant. Anyway it works on revision fdeb1729. I've tried to rebase it on never versions (1.7.0 including), but no luck yet.

Ant-ON commented 3 years ago

@kwarek Can you test 1.7.0 version without patch?

kwarek commented 3 years ago

Sorry, attaching patch failed.

0001-enable-stm32g030.patch.txt

Yes, i've tested it. It doesn't work: "WARN common.c: NRST is not connected" But obviously it it connected.

Ant-ON commented 3 years ago

@kwarek Can you check 1.7.0 with these fixes? The rest of the changes seem superfluous to me...

0001-enable-stm32g030.patch.txt

kwarek commented 3 years ago

No, it doesn't work (NRST is not connected). Also, patched fdeb172 gives:

INFO common.c: G030/G031/G041 with error: 8 KiB SRAM, 32 KiB flash in at least 2 KiB pages. INFO common.c: Attempting to write 6960 (0x1b30) bytes to stm32 address: 134217728 (0x8000000) INFO common.c: Flash page at addr: 0x08000000 erased INFO common.c: Flash page at addr: 0x08000800 erased INFO common.c: Flash page at addr: 0x08001000 erased INFO common.c: Flash page at addr: 0x08001800 erased INFO common.c: Finished erasing 4 pages of 2048 (0x800) bytes Writing Starting 3 page write INFO common.c: Starting verification of write complete INFO common.c: Flash written and verified! jolly good!

But, patched (and ultimately not working) 1.7.0 gives:

INFO common.c: G030/G031/G041 with error: 8 KiB SRAM, 11868 KiB flash in at least 2 KiB pages. INFO common.c: Attempting to write 6960 (0x1b30) bytes to stm32 address: 134217728 (0x8000000) ERROR common.c: Flash memory is write protected ERROR common.c: Flash programming error: 0x00000248 ERROR common.c: Failed to erase_flash_page(0x8000000) == -1 stlink_fwrite_flash() == -1

So there is problem with detecting flash size.

Ant-ON commented 3 years ago

@kwarek Have you tried using --connect-under-reset? It is also possible to override the size of the flash memory (--flash=32k), but this does not solve the main problem.

kwarek commented 3 years ago

I'm using --connect-under-reset all the time. Without it, it doesn't have chance to work. swd and swclk are used as gpio. In mcu with 5 gpio, every pin counts :)

Ant-ON commented 3 years ago

@kwarek In this case, I still have no idea why this is happening. I will try to repeat the problem in the evening. I have board with stm32g0 and I can disable the reset using the NRST pin. Can you give the full log of version 1.7.0 with the patch?

kwarek commented 3 years ago

I suspect that the reason is that core doesn't stay halted. Main part of my patch is substitution of stlink_force_debug with stlink_step in two places. If I interpret it correctly stlink_force_debug doesn't stop core, but stlink_step does. About NRST pin - in stm32g031 it can be disabled, in stm32g030 it can't.

Ant-ON commented 3 years ago

@kwarek This is unlikely. On stlink v2 +, both commands work using the same DHCSR register. Most likely, the controller does not fully start up after a reset. Perhaps after soft reset it is necessary to add a delay of ~10ms: https://github.com/stlink-org/stlink/blob/eeaef981a5dcf6bec6d9b6cada398abcf34b8737/src/common.c#L4757

kwarek commented 3 years ago

0001-add-stm32g030-2.patch.txt stlink170.log

In case of 1.7.0 i think the main problem is that every stlink_read_debug32 returns 0x20002e5c.

Ant-ON commented 3 years ago

@kwarek Judging by the log, there is a possibility that the soft reset function does not wait for the end of the reboot (fortunate garbage is read from the registers while waiting). For this reason, garbage begins to be read in the next code. Try adding usleep(10000); after https://github.com/stlink-org/stlink/blob/eeaef981a5dcf6bec6d9b6cada398abcf34b8737/src/common.c#L4757

kwarek commented 3 years ago

Nothing has changed (still 2e5c everywhere).

Ant-ON commented 3 years ago

@kwarek You can also try rewriting the reset function. Change this part of function https://github.com/stlink-org/stlink/blob/eeaef981a5dcf6bec6d9b6cada398abcf34b8737/src/common.c#L1725-L1745 to

  // waiting for a reset within 500ms
  // DDI0337E, p. 10-4, Debug Halting Control and Status Register
  cortex_m3_cpuid_t cpu_id;
  timeout = time_ms() + 500;
  while (time_ms() < timeout) {
    // Read the CPU ID to determine target is come back from reset state
     if (stlink_cpu_id(sl, &cpu_id) ||
         cpu_id.implementer_id != STLINK_REG_CMx_CPUID_IMPL_ARM) {
      continue;
    }

    // DDI0337E, p. 10-4, Debug Halting Control and Status Register
    dhcsr = STLINK_REG_DHCSR_S_RESET_ST;
    stlink_read_debug32(sl, STLINK_REG_DHCSR, &dhcsr);
    if ((dhcsr & STLINK_REG_DHCSR_S_RESET_ST) == 0) {
      if (halt_on_reset) {
        // waiting halt by the SYSRESETREQ exception
        // DDI0403E, p. C1-699, Debug Fault Status Register
        dfsr = 0;
        stlink_read_debug32(sl, STLINK_REG_DFSR, &dfsr);
        if ((dfsr & STLINK_REG_DFSR_VCATCH) == 0) {
          continue;
        }
      }
      timeout = 0;
      break;
    }
  }
kwarek commented 3 years ago

Now (1.7.0 with change above) I get:

2021-04-26T11:50:00 WARN common.c: NRST is not connected 2021-04-26T11:50:00 ERROR common.c: Soft reset failed: timeout 2021-04-26T11:50:00 ERROR common.c: Can not connect to target. Please use 'connect under reset' and try again

with --debug, before timeout there are lines:

DEBUG common.c: *** stlink_read_debug32 0x20002e5c at 0xe000ed00

Ant-ON commented 3 years ago

@kwarek Hmm... Perhaps, while waiting for a reset via the NRST pin, the target is startuped and switch the SWD pins to the gpio. We can try to replace https://github.com/stlink-org/stlink/blob/eeaef981a5dcf6bec6d9b6cada398abcf34b8737/src/common.c#L4747 to

  unsigned timeout = time_ms() + 10;
  while (time_ms() < timeout) {
    stlink_force_debug(sl);
    usleep(1000);
  }
kwarek commented 3 years ago

I was trying port my patch to newer versions. While with fdeb172 is works, with 373eee (next compilable version) is does not. 373eee_no_ts.log fdeb172_no_ts.log

so, starting (at least) with 373eee every stlink_read_debug32 returns 2E5C (at least with my modification). first difference (from above logs):

DEBUG common.c: core_id = 0x0bc11477 - DEBUG common.c: stlink_read_debug32 0000000000 at 0xe0042000 - DEBUG common.c: stlink_read_debug32 0x20002e5c at 0x5c001000 - DEBUG common.c: stlink_read_debug32 0xffff0020 at 0x1fff75e0 - INFO common.c: G030/G031/G041 with error: 8 KiB SRAM, 32 KiB flash in at least 2 KiB pages. + DEBUG common.c: stlink_read_debug32 0x20002e5c at 0xe0042000 + DEBUG common.c: stlink_read_debug32 0x20002e5c at 0x1fff75e0 + INFO common.c: G030/G031/G041 with error: 8 KiB SRAM, 11868 KiB flash in at least 2 KiB pages. DEBUG common.c: stlink current mode: debug (jtag or swd) DEBUG common.c: stlink current mode: debug (jtag or swd) DEBUG common.c: stlink_step DEBUG common.c: stlink_status *** - DEBUG usb.c: core status: 00030003 - DEBUG common.c: core status: halted + DEBUG usb.c: core status: 20002E5C + DEBUG common.c: core status: running

kwarek commented 3 years ago

Almost! Clean 1.7.0 with only change:

  unsigned timeout = time_ms() + 10;
  while (time_ms() < timeout) {
    stlink_force_debug(sl);
    usleep(1000);
  }

works. But only one time. After connecting st-link first run gives:

INFO common.c: G030/G031/G041: 8 KiB SRAM, 32 KiB flash in at least 2 KiB pages. file build/ch.bin md5 checksum: 88e99cecd3ae39cfda1fdde8110b9b0, stlink checksum: 0x00084507 INFO common.c: Attempting to write 6960 (0x1b30) bytes to stm32 address: 134217728 (0x8000000) INFO common.c: Flash page at addr: 0x08000000 erased INFO common.c: Flash page at addr: 0x08000800 erased INFO common.c: Flash page at addr: 0x08001000 erased INFO common.c: Flash page at addr: 0x08001800 erased INFO common.c: Finished erasing 4 pages of 2048 (0x800) bytes INFO common.c: Starting Flash write for WB/G0/G4 2/ 3 pages written INFO common.c: Starting verification of write complete INFO common.c: Flash written and verified! jolly good!

and second:

WARN common.c: NRST is not Connected ERROR common.c: Can not connect to target. Please use 'connect under reset' and try again Failed to connect to target

Ant-ON commented 3 years ago

@kwarek It seems we have found the cause of the problem. You can try changing the delay from 1000 to 500. I do not still see any other possible reasons for not working the second time. Only delay of switching to debug.

kwarek commented 3 years ago

Changing to 500 doesn't help. Also after the failure the LED stops blinking, so maybe cpu is halted?

Ant-ON commented 3 years ago

@kwarek Stopping blinking most likely means that there is no communication between the debugger and the target. Do you press the reset button on second connection attempts?

kwarek commented 3 years ago

No, I have no reset button (it's diy board). I plug/unplug usb connector. Unfortunatelly current code doesn't work deterministically. Sometimes 1st try doesn't work, but 2nd does. Sometimes 10(and more) tries fail. After failure I have to unplug for serveral seconds, but sometimes short plug/unplug cycle is enough. Strange.

Also, I've tried different usleep values, but didn't notice any difference.

Ant-ON commented 3 years ago

@kwarek There might be a problem with the hardware right now. For example, the capacities do not have time to discharge, which does not allow to turn offs the target. The programming connector can also supply current.

kwarek commented 3 years ago

Yes, it's possible (my board is powered from st-link). But sometimes after long power off and pluging st-link in, all tries fail. Doing another power cycle(s) fixes that. Patched fdeb172 works (maybe by accident) every time.

Ant-ON commented 3 years ago

@kwarek Perhaps this is a fortunate combination of delays. I think this is the race effect. In addition to changing the usleep to while..., you can try commenting out:

    // minimum reset pulse duration of 20 us (RM0008, 8.1.2 Power reset)
    usleep(20);
kwarek commented 3 years ago

No change unfortunately. But I think the problem might be before the new loop.

// clear S_RESET_ST in DHCSR register stlink_read_debug32(sl, STLINK_REG_DHCSR, &dhcsr);

stlink_jtag_reset(sl, STLINK_JTAG_DRIVE_NRST_HIGH);

After a loop, I've added printing dhcsr (which is read before loop). When it's ok, it's read as 0x2000001 , but when it's not it's of course 0x20002E5C.

Ant-ON commented 3 years ago

@kwarek Yes, you may be right. You can move init SWD mode to start of stlink_target_connect function:

    if (stlink_current_mode(sl) != STLINK_DEV_DEBUG_MODE) {
      stlink_enter_swd_mode(sl);
    }

Or comment DHCSR register clearing:

stlink_read_debug32(sl, STLINK_REG_DHCSR, &dhcsr);

If the stlink is not switched to the SWD mode, writing data to the register can lead to incomprehensible situation

Ant-ON commented 3 years ago

@kwarek I tried to make the connect under reset more stable. This option seems to work better:

int stlink_target_connect(stlink_t *sl, enum connect_type connect) {
  uint32_t dhcsr;

  if (stlink_current_mode(sl) != STLINK_DEV_DEBUG_MODE) {
    stlink_enter_swd_mode(sl);
  }

  if (connect == CONNECT_UNDER_RESET) {
    /* Try to halted core before reset. It need for stop core without 
     * connect NRST pin before any init procedure */
    unsigned timeout = time_ms() + 5;
    while (time_ms() < timeout) {
      sl->backend->force_debug(sl);
      usleep(100);
    }

    /* Reset core throught NRST pin
     * Minimum reset pulse duration of 20 us (RM0008, 8.1.2 Power reset)*/
    stlink_jtag_reset(sl, STLINK_JTAG_DRIVE_NRST_LOW);
    usleep(20);
    // clear S_RESET_ST in DHCSR register
    stlink_read_debug32(sl, STLINK_REG_DHCSR, &dhcsr);
    stlink_jtag_reset(sl, STLINK_JTAG_DRIVE_NRST_HIGH);

    /* Try to halted core after reset */
    timeout = time_ms() + 10;
    while (time_ms() < timeout) {
      sl->backend->force_debug(sl);
      usleep(100);
    }

    /* Check reset flag */
    dhcsr = 0;
    stlink_read_debug32(sl, STLINK_REG_DHCSR, &dhcsr);
    if ((dhcsr & STLINK_REG_DHCSR_S_RESET_ST) == 0) {
      printf("NRST is not connected\n");
    }

    /* addition soft reset for halt before the first instruction */
    stlink_soft_reset(sl, 1 /* halt on reset */);
  } else if (connect == CONNECT_NORMAL) {
    stlink_reset(sl, RESET_AUTO);
  }

  return stlink_load_device_params(sl);
}
kwarek commented 3 years ago

Last change doesn't seem to work. I've tried 10 times (clean 1.7.0 with function from above), and every time I got:

NRST is not connected ERROR common.c: Soft reset failed: timeout ERROR common.c: Can not connect to target. Please use 'connect under reset' and try again Failed to connect to target

Moving stlink_enter_swd_mode(sl) up or commenting out stlink_read_debug32(sl, STLINK_REG_DHCSR, &dhcsr) didn't help either.

kwarek commented 3 years ago

I've found a partial fix. If call to stlink_enter_swd_mode is unconditional, it works every time, provided that it worked the first time after pluging in st-link. Patch: stlink170.diff.log. Unfortunately, sometimes after pluging in st-link it doesn't work (and it doesnt work in consecutive tries) with:

WARN common.c: NRST is not Connected ERROR common.c: Can not connect to target. Please use 'connect under reset' and try again Failed to connect to target

Ant-ON commented 3 years ago

@kwarek What if we move stlink_enter_swd_mode(sl) to the beginning of the function and do it call is unconditional? I plan to move this call to the initialization of usb....

kwarek commented 3 years ago

Works less often than before.

kwarek commented 3 years ago

I think I found solution. 1.7.0 with attached changes works for me every time. stlink170ok.diff.log moving stlink_jtag_reset after stlink_soft_reset causes st-flash to work the 1st time after puging in st-link, making stlink_enter_swd_mode unconditional causes it to work subsequent times. One drawback is that every time there is message:

ERROR common.c: Soft reset failed: timeout

But otherwise it's ok.

Nightwalker-87 commented 3 years ago

I think this might break something that has been fixed recently.

kwarek commented 3 years ago

Maybe stlink_force_debug doesn't halt core? Then after setting NRST to high cpu starts running, and if it manages to execute instructions to switch swclk/swdio to gpio mode, then we won't be able to connect to it anymore.

Nightwalker-87 commented 3 years ago

@Ant-ON: How shall we proceed here?

Ant-ON commented 3 years ago

@kwarek Can you try this branch https://github.com/Ant-ON/stlink/tree/connect_under_reset_rework ?

kwarek commented 3 years ago

It works, but on second and subsequent run. First time after pluging-in stlink I get this:

st-flash 1.6.1-322-gb453ca3 WARN common.c: NRST is not connected ERROR common.c: Soft reset failed: timeout ERROR common.c: Can not connect to target. Please use 'connect under reset' and try again

This is reproducible.

Ant-ON commented 3 years ago

@kwarek Can you try the same branch again? Maybe I was able to make the result more stable...

Nightwalker-87 commented 3 years ago

@Ant-ON: Great work. However I take note of that the version string is still wrong on this branch. Why is this? I believe to have fixed it already. Is there anything missing?

kwarek commented 3 years ago

No, it's worse. Sometimes after pluging-in stlink it works right away, sometimes on 2nd try, sometimes on 3rd, and sometimes it doesn't work at all.

st-flash 1.6.1-323-g22fba02 WARN common.c: NRST is not connected ERROR common.c: Can not connect to target. Please use 'connect under reset' and try again Failed to connect to target

Ant-ON commented 3 years ago

@kwarek I no longer understand what could be the reason for this behaviour... My boards work out quite well. I added checking the status of the execution of commands. Can you try this branch again https://github.com/Ant-ON/stlink/tree/connect_under_reset_rework? If there are errors is remain, you can attach the log with the --debug argument

Nightwalker-87 commented 3 years ago

@kwarek: Maybe we are facing a local hardware issue here. However I would prefer, if you do some local investigation for yourself and collect some useful information that can help to investigate the issue. Currently we seem to be looking at a "try this - it doesn't work" endless loop, which does not seem to move any forward and may appear annoying to contributors willing to help. Please consider this and return with a set of useful info. You may also make use www.pastebin.org to post certain output.

kwarek commented 3 years ago

My investigation ended with working solution (no errors): https://github.com/stlink-org/stlink/issues/1098#issuecomment-828784766, but I understand it might conflict with something else.

Latest version works slightly better (~50% of the time). If it doesn't, there is an error:

st-flash 1.6.1-324-g03ad4a4 WARN common.c: NRST is not connected ERROR common.c: Soft reset failed: error write to AIRCR ERROR common.c: Can not connect to target. Please use 'connect under reset' and try again Failed to connect to target

And with --debug:

DEBUG common.c: looking up stlink version DEBUG common.c: st vid = 0x0483 (expect 0x0483) DEBUG common.c: stlink pid = 0x3748 DEBUG common.c: stlink version = 0x2 DEBUG common.c: jtag version = 0x15 DEBUG common.c: swim version = 0x4 DEBUG common.c: stlink current mode: dfu DEBUG usb.c: -- exit_dfu_mode DEBUG usb.c: JTAG/SWD freq set to 0 DEBUG common.c: stlink_enter_swd_mode DEBUG common.c: stlink_jtag_reset 0 DEBUG common.c: stlink_jtag_reset 1 DEBUG usb.c: I/O: error status (0x12) of command (0x35F2) DEBUG usb.c: I/O: error status (0x12) of command (0x35F2) DEBUG usb.c: I/O: error status (0x12) of command (0x35F2) DEBUG usb.c: I/O: error status (0x12) of command (0x35F2) DEBUG usb.c: I/O: error status (0x12) of command (0x35F2) DEBUG usb.c: I/O: error status (0x12) of command (0x35F2) DEBUG usb.c: I/O: error status (0x12) of command (0x35F2) DEBUG usb.c: I/O: error status (0x12) of command (0x35F2) DEBUG usb.c: I/O: error status (0x12) of command (0x35F2) DEBUG usb.c: I/O: error status (0x12) of command (0x35F2) DEBUG usb.c: I/O: error status (0x12) of command (0x35F2) DEBUG usb.c: I/O: error status (0x12) of command (0x35F2) DEBUG usb.c: I/O: error status (0x12) of command (0x35F2) DEBUG usb.c: I/O: error status (0x12) of command (0x35F2) DEBUG usb.c: I/O: error status (0x12) of command (0x35F2) DEBUG usb.c: I/O: error status (0x12) of command (0x35F2) DEBUG usb.c: I/O: error status (0x12) of command (0x35F2) DEBUG usb.c: I/O: error status (0x12) of command (0x35F2) DEBUG usb.c: I/O: error status (0x12) of command (0x35F2) DEBUG usb.c: I/O: error status (0x12) of command (0x35F2) DEBUG usb.c: I/O: error status (0x12) of command (0x35F2) DEBUG usb.c: I/O: error status (0x12) of command (0x35F2) DEBUG usb.c: I/O: error status (0x12) of command (0x36F2) WARN common.c: NRST is not connected DEBUG common.c: stlink_soft_reset (halt) DEBUG common.c: stlink_write_debug32 0xa05f0003 to 0xe000edf0 DEBUG usb.c: I/O: error status (0x12) of command (0x35F2) DEBUG common.c: stlink_write_debug32 0x01000501 to 0xe000edfc DEBUG usb.c: I/O: error status (0x12) of command (0x35F2) DEBUG common.c: stlink_write_debug32 0x00000008 to 0xe000ed30 DEBUG usb.c: I/O: error status (0x12) of command (0x35F2) DEBUG usb.c: I/O: error status (0x12) of command (0x36F2) DEBUG common.c: stlink_write_debug32 0x05fa0004 to 0xe000ed0c DEBUG usb.c: I/O: error status (0x12) of command (0x35F2) ERROR common.c: Soft reset failed: error write to AIRCR DEBUG common.c: stlink current mode: debug (jtag or swd) DEBUG common.c: Loading device parameters.... DEBUG common.c: stlink_core_id DEBUG common.c: core_id = 0x0bc11477 DEBUG usb.c: I/O: error status (0x12) of command (0x36F2) ERROR common.c: Can not connect to target. Please use 'connect under reset' and try again DEBUG common.c: stlink_exit_debug_mode DEBUG common.c: stlink_close ***

Ant-ON commented 3 years ago

@kwarek 0x12 is the SWD_AP_ERROR. Perhaps the microcontroller has time to change the state of the GPIO before the stlink has time to send the halt command.

About stlink170ok.diff.log. stlink_jtag_reset cannot be move, as this will break the connection support when the NRST pin is connected. Untill executing stlink_jtag_reset(sl, STLINK_JTAG_DRIVE_NRST_HIGH); the microcontroller be in a reset state.

kwarek commented 3 years ago

stlink_jtag_reset cannot be move, as this will break the connection support when the NRST pin is connected.

But the NRST pin is connected to mcu. It has to be. The whole point is that for SWD to work, cpu has to be prevented from running user code (because in it SWD gets disabled). From what I understand, for the programming to work reliably the core has to be halted when we exiting reset, and stay halted until we end programming flash. Otherwise we get a race.

Ant-ON commented 3 years ago

@kwarek For a couple of days I tried to repeat the situation. I rolled back the st-link to version V2J21S4. I wrote a firmware with disabling the SWD and JTAG at the beginning of the main() for STM32F1. It is stably flashing... The whole situation really looks like a race. But if the NRST is connected, they have nowhere to come from... The only thing that comes to mind: perhaps there is an RC filter with a large time constant along the NRST circuit?

kwarek commented 3 years ago

Maybe stm32g0 is a little different? NRST is connected to 100nF capacitor. (as suggested in datasheet) I've just checked (connect_under_reset_rework branch, cab9fc42) with another board with only STM32G030F(NRST is not shared with gpio) and two capacitors. And the result is the same - sometimes it works, sometimes it doesn't with the same error message as https://github.com/stlink-org/stlink/issues/1098#issuecomment-841877191

kwarek commented 3 years ago

Also, I'm using stlink v2 clone. They don't have NRST connected, so i've added it through 120ohm resistor (similar to https://ziutek.github.io/2018/03/26/stlink.html). Maybe that causes the delay ?

Ant-ON commented 3 years ago

@kwarek Resistances of tens of ohms are usually used as a current-limiting resistance. Circuits of st-link part of Discovery board use a 22 Ohm resistor on the SWD pins. In theory, increasing this delay should improve the situation: https://github.com/Ant-ON/stlink/blob/cab9fc4210ac090da6b7e45d91ffd300549a9436/src/common.c#L4908-L4909 But something more definite can be said only by the oscillograms of the NRST pin.