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.