Connecting under reset not working

[anyn99]

I have a custom board with an STM32L432KB.
There was some trouble when trying to attach to it, scanning worked fine most of the time.
I did some, well quite a lot of debugging, and it seems that the issue is related to my board.
It has only two layers and the SWDCLK and SDWIO traces are routed all over the place - they are simple button inputs when not debugging. The BMP code as it is, is just to fast for this! :-)

Would it be possible to add some kind of speed setting that can be set in the monitor menu?

I did something like this:

void delay(unsigned int ticks)
{
volatile unsigned int i;
for (i = 0; i < ticks; i++)
  {
    asm("nop");
  }
}

And then at every clock out in /platforms/common/swdptap.c

gpio_set(SWCLK_PORT, SWCLK_PIN);
delay(DEFAULT_DELAY);
gpio_clear(SWCLK_PORT, SWCLK_PIN);
delay(DEFAULT_DELAY);

Actually with a DEFAULT_DELAY of 1, the code already worked flawlessly for me, so I am not completly sure if it isn't really a timing (compiler over-optimizing?!) issue

[UweBonnes]

Are you using git head? Git Head has no sequence to
bla()
gpio_set()
gpio_clear()
bla()

Either gpio_set() is already doubled or there are other commands in between. So the time the signals are high is already extended as before e54a826 (loop unrolling). Even before with the short high times, BMP worked for many boards.

Adding a function call in the unrolled loops with result in substantial longer programming times.

Did you look at the signals on your board with a scope? Can you compare against against e.g. a BMP modified Nucleo Board?

[anyn99]

yes i use the current head, but modified it until it works for me, sorry for being unclear about that.
Here some more info. I actually don't use original BMP, but ST-LINK v2 "Baite" clone.
Sorry that i can't compare to a different BMP probe....

I started using the code as is, with gpio_set() doubled in swdptap.c, scanning worked fine, but when attaching the probe failed everytime at the first adiv5_swdp_low_access. After the register write (8 bits) the ack was always 111 (0x7) instead of 100 or 010 or at least 001. So i think it was a timing issue on the bus.
Maybe i will try to doube the gpio_clear()s as well and see if it works.
I did scope a little bit, but i couldn't find a problem so far. I can't directly get the signal at the STM32L4, but only at the pin header after the signals were routed over the board.

Anyway, this issue may or may not be related with the STM32L4 being in STOP mode most of the time and the SWDIO/SWCLK pins being disabled by software, so i have to connect under reset and then load my binary. The main problem here is the cortexm_force_halt(), because it releases srst and waits for the mcu to halt, which is of course not working with this setup i have.
So this also doesn't work as intended. I will try to sort things out as soon as i have time for it and then let you know more...

[UweBonnes]

Did you try "mon assert_srst attach"

[anyn99]

Yes i did, but as mentioned already, this is not sufficient since it asserts just before attaching. During attach, there is a call to cortexm_force_halt() which deasserts srst!

[UweBonnes]

It is good to keep all relevant information in one thread. You probably mentioned the fact in another thread...

Perhaps "Request halt on reset" should be sent to the Cortex-M before scanning when "mon assert_srst attach" is active? Can you try?

[anyn99]

Sorry, didn't mean to be rude. I just wrote that i “connect under reset“, not that i do it with “mon ass attach“, my mistake.

Actually your suggestion sounds like a very good solution! I will try that and report back!

[anyn99]

Fixed!
In the end it was little more than moving one line of code....
Created a pull request...

I hope that doesn't break compatibility with not connecting under reset...

Ah and just to explicitly mention it, the swd timing is fine and working very well!
I got 35 kB/s on this Baite ST-Link v2 clone with a STM32F101CB on it.

[anyn99]

newest fixes make stm32l4 work properly, also while in sleep/stop and with or without reset.
see #399 and #432.