Could assert_srst be forced for stm32l0?

[tve]

I've had a hell of a time scanning for STM32L0's that are in stop mode until I figured out I needed assert_srst=scan (introduced in 44fc24e). Is there a way to do this automatically?

What I notice is that if an STM32L0 is in stop mode and reset is not asserted the BMP hangs in https://github.com/blacksphere/blackmagic/blob/master/src/target/adiv5.c#L417-L419
But adiv5_dp_init is called from https://github.com/blacksphere/blackmagic/blob/master/src/target/adiv5_swdp.c#L81 at which point the device IDCODE is known, could that be used to determine whether srst is required?

I assume there are use-cases where the MCU is not in stop mode and someone wants to connect without resetting it. So perhaps at least the wait-for-ack could have a time-out and print the suggestion to use assert_srst ?

[UweBonnes]

Asserting SRST automatically will inhibit connecting to a crashed CPU with crashed program. Wiping out the program state by a reset by default is not a good idea. So I think active user intervention (assert_srst=scan) is a good compromise.

Doesn't https://github.com/blacksphere/blackmagic/blob/master/src/target/adiv5.c#L417-L419 time out after 2 or maybe 2 * 20 seconds? Did you try implementing your suggestion?

[tve]

I'm seeing a related issue. I have an stm32l0 that mostly sits in stop mode and briefly wakes up every 2 seconds. I set monitor assert_srst scan. I run swdp_scan and the MCU is detected. Great. But then I try to attach and it systematically fails, e.g.:

Attaching to program: /home/src/goobies/goobies/rftemp/.pioenvs/jnz1/firmware.elf, Remote target
Attaching to Remote target failed

The pgm I'm running sits in stop mode for 2 seconds, then wakes up and prints something on the uart. Looking at the uart output I noticed that the swdp_scan causes a reset as expected. But after the scan the program continues and by the time I type the attach command the MCU is back in stop mode.
I then put the target, mon assert_srst, mon swdp_scan, and attach commands into .gdbinit and it works perfectly because the attach happens before the MCU gets far enough into the program to hit stop. It seems that in order to attach the MCU has to be srst reset again.

[tve]

Doesn't https://github.com/blacksphere/blackmagic/blob/master/src/target/adiv5.c#L417-L419 time out after 2 or maybe 2 * 20 seconds? Did you try implementing your suggestion?

Well, there is a time-out, but that doesn't help if it's not triggered :-). What I'm seeing right now is that ADIV5_DP_CTRLSTAT_CSYSPWRUPACK | ADIV5_DP_CTRLSTAT_CDBGPWRUPACK aren't coming on regardless of how many times they're being read. The ctrlstat register value coming back from the adiv5_dp_read is 0x40. So somehow the write to bring power up didn't work (not sure why yet). But there are a number of potentially infinite while loops in adiv5_dp_init...

[UweBonnes]

Thorsten,

was your last comment already with #391 applied? If not , your analysis "So somehow the write to bring power up didn't work (not sure why yet)" correlates good to the STM32 remark about the needed two additional SWD cycles:"This is particularly important when writing the CTRL/STAT for a power-up request. If the next transaction (requiring a power-up) occurs immediately, it will fail."

[tve]

Yes, I had the extra idle cycles. Even increased it to 4 just to see. I spent a couple of hours troubleshooting, attaching scope and manually verifying the bits, adding debug printf's. It all looked correct, but the chip just didn't actually power up the domains. When I reached a dead end a lightbulb went on and I power cycled the thing. Guess what, it worked right away w/out any code change and repeatedly. So there are funny states that don't get reset by the reset line, only by power cycle. Argh!

[UweBonnes]

Yes, many debug related registers are only reset by Power Up.

Are your problems now solved?

[tve]

Dunno yet, I have to unwind a pile of debug stuff :-). Also, I noticed that the bit banging in swdptap.c isn't that great. For example, the way the 'out' functions are written the set-up time of swdio before swclk rising is very short. With imperfect debug cables there is extremely little room for reflections or x-talk. Is there a reason you keep swdclk idle low, instead of keeping it idle high which would allow you to increase the set-up time considerably without slowing things down?

[esden]

@tve any updates on this? Were you able to test more? As this issue is a bit stale, and the bitbanging did get some improvements since this was filed I will close this issue. If there is more work to be done here please feel free to reopen this issue with additional information.