You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
[reset] Reset and force debug for Cortex M0 targets #332
It seems that for CortexM0 targets, tested with STM32L053, memory and memory mapped registers cannot be accesed with _stlink_usb_read_debug32 unless the core is halted in debug state after a call to stlink_force_debug(sl). Resetting the core seems to start it again. This has implications for how we can identify the chip reading the cip-id registers.
For cortex M3 and M4 the memory is accessible from the debugger while the core and a program is running so this is not an issue for these cores.
Now the three programs st-util, st-flash and st-info have different behavior and therefore works and fails under different circumstances, making the situation confusing.
st-util normally halts and enters debug mode before handing control to gdb, and calls open with resetflag 0, stlink_open_usb(state.logging_level, 0); and it correctly identifies STM32L053
st-flash must enter debug mode to run RAM based flash loaders, calls open with reset flag 1, stlink_open_usb(state.logging_level, 1); and it fails to identify STM32L053
st-info calls open with reset flag 1, stlink_open_usb(state.logging_level, 1); and it fails to identify STM32L053
This is a bit of a mess and it should be cleaned up, so input is wanted, we dont want to break what is working.
@Nightwalker-87
I think it might be closed by #1114
The behavior is now more standardized. All applications are called with reset 1 (normal). You can switch to reset 2 (connect under reset) by command line argument. st-info and st-util can use reset 0 (hot plug).
@Ant-ON I have taken note of that, but was pointing at
The behavior is now more standardized. All applications are called with reset 1 (normal). You can switch to reset 2 (connect under reset) by command line argument. st-info and st-util can use reset 0 (hot plug).
on the code-layer and not on the command line level.
@Nightwalker-87 in command line layer too. See --hot-plug and --connect-under-reset in tutorial.md.
I no added the --connect-under-reset to gdb. I don't know how to do it there yet. I will add the --hot-plug to the st-flash at evning.
Ah now I get it - reset 0, 1 & 2 sounded like enum cases in the code to me at first... That's fine then.
I was aware of the mentioned command options being listed in the tutorial, as you mentioned it above.
Activity
xor-gate commentedon May 20, 2016
This should be fixed in latest
v1.2.0andmaster, could you verify?24 remaining items
Ant-ON commentedon Mar 31, 2021
@Nightwalker-87
I think it might be closed by #1114
The behavior is now more standardized. All applications are called with reset 1 (normal). You can switch to reset 2 (connect under reset) by command line argument.
st-infoandst-utilcan use reset 0 (hot plug).Nightwalker-87 commentedon Mar 31, 2021
I think this should be documented before we close this issue.
Ant-ON commentedon Apr 1, 2021
@Nightwalker-87 I added information about args to https://github.com/stlink-org/stlink/blob/develop/doc/tutorial.md
Nightwalker-87 commentedon Apr 2, 2021
@Ant-ON I have taken note of that, but was pointing at
on the code-layer and not on the command line level.
Ant-ON commentedon Apr 5, 2021
@Nightwalker-87 in command line layer too. See
--hot-plugand--connect-under-resetintutorial.md.I no added the
--connect-under-resetto gdb. I don't know how to do it there yet. I will add the--hot-plugto thest-flashat evning.Nightwalker-87 commentedon Apr 5, 2021
Ah now I get it - reset 0, 1 & 2 sounded like enum cases in the code to me at first... That's fine then.
I was aware of the mentioned command options being listed in the tutorial, as you mentioned it above.
Nightwalker-87 commentedon Apr 5, 2021
As #1114, which addresses this ticket, also includes the related documentation, we can now close this issue as resolved.