[STM32G031]: can't connect to target: unknown chip id (--connect-under-reset not working) #1098
Comments
Nightwalker-87
added
component/st-flash
os/windows
programmer/STLINK/V3
The STM32H7_CORE_ID value in the manual is 0x6b00477, however it was incorrectly set in stm32.h to 0x6b002477 Fixes stlink-org#1098
|
Hello, |
|
@kwarek Can you test 1.7.0 version without patch? |
|
Sorry, attaching patch failed. 0001-enable-stm32g030.patch.txt Yes, i've tested it. It doesn't work: |
|
@kwarek |
|
No, it doesn't work (NRST is not connected). Also, patched fdeb172 gives:
But, patched (and ultimately not working) 1.7.0 gives:
So there is problem with detecting flash size. |
|
@kwarek Have you tried using |
|
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 :) |
|
@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? |
|
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. |
|
0001-add-stm32g030-2.patch.txt In case of 1.7.0 i think the main problem is that every stlink_read_debug32 returns 0x20002e5c. |
|
Nothing has changed (still 2e5c everywhere). |
|
@kwarek You can also try rewriting the reset function. Change this part of function Lines 1725 to 1745 in eeaef98 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;
}
} |
|
Now (1.7.0 with change above) I get:
with --debug, before timeout there are lines:
|
|
I was trying port my patch to newer versions. While with fdeb172 is works, with 373eee (next compilable version) is does not. so, starting (at least) with 373eee every stlink_read_debug32 returns 2E5C (at least with my modification).
|
|
Almost! Clean 1.7.0 with only change:
works. But only one time. After connecting st-link first run gives:
and second:
|
|
@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 I no longer understand what could be the reason for this behaviour... My boards work out quite well. |
|
@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. |
|
My investigation ended with working solution (no errors): #1098 (comment), 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:
And with --debug:
|
|
@kwarek About |
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. |
|
@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... |
|
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, cab9fc4) 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 #1098 (comment) |
|
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 ? |
|
@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. |
|
@Ant-ON Is this completely or only partially fixed by now? |
|
@Nightwalker-87 It's partial solution. The problem is not clear. There may be problems in the hardware. |
|
Can we take any technical benefit from this issue? |
|
@Nightwalker-87 I've changed my workflow a bit, so I can't provide more details or test new solutions regarding that issue |
|
As the original setup is no longer available, there is no possibility to investigate any further (hardware-related) details. |
Nightwalker-87
added
status/resolved
bug/fixed
component/stlink-lib
and removed
needs/investigation
needs/testing
labels
st-flashCommandline-Output:
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-flashfails to read chip idIt looks like
--connect-under-resetparam doesn't have any effect. At the same time, I can use the samest-flashconfig to program all my other boards.STM32CubeProgrammer log:
The text was updated successfully, but these errors were encountered: