boards/stm32: generalize use of connect_assert_srst for flashing #12158

aabadie · 2019-09-03T06:26:28Z

Contribution description

This PR is a follow-up and generalization of #11976 to all nucleo. The common OpenOCD confguration for stm32l0 based boards is also adapted (removed use of connect_assert_srst) and related boards (b-l072z-lrwan1, lsn50, i-nucleo-lrwan1) are adapted as well.

There are other boards using stlink that could be also adapted: stm32 discovery boards, stm32f108, b-l475e-iot01a and ublox-c030-u201.

Testing procedure

Same testing procedure as the one in #11976 but for all mentioned boards (all nucleo + stm32l0 based boards)

Issues/PRs references

Follow-up of #11976.

This allows to flash/reset even over a crashed or sleeping firmware

fjmolinas · 2019-09-10T07:53:24Z

Same testing procedure as the one in #11976 but for all mentioned boards (all nucleo + stm32l0 based boards)

The test procedure was very specifig of the nucleo-f091rc case since it was easily shown by specifig applications.

I'll test that it workd on stm32l0 boards, for nucleo I'll just launch tests on local-ci.

fjmolinas · 2019-09-13T07:32:42Z

I'm having some flashing issues with a couple of boards, not sure if the issue is on my CI or OPENOCD_RESET_USE_CONNECT_ASSERT_SRST is not enough for all cases.

none separate
srst_only separate srst_nogate srst_open_drain connect_deassert_srst
srst_only separate srst_nogate srst_open_drain connect_assert_srst
Info : Unable to match requested speed 500 kHz, using 480 kHz
Info : Unable to match requested speed 500 kHz, using 480 kHz
Info : clock speed 480 kHz
Error: libusb_open() failed with LIBUSB_ERROR_ACCESS
Info : STLINK v2 JTAG v28 API v2 SWIM v18 VID 0x0483 PID 0x374B
Info : using stlink api v2
Info : Target voltage: 3.256693
Info : stm32l4x.cpu: hardware has 6 breakpoints, 4 watchpoints
    TargetName         Type       Endian TapName            State
--  ------------------ ---------- ------ ------------------ ------------
 0* stm32l4x.cpu       hla_target little stm32l4x.cpu       running
Info : Unable to match requested speed 500 kHz, using 480 kHz
Info : Unable to match requested speed 500 kHz, using 480 kHz
adapter speed: 480 kHz
Error: timed out while waiting for target halted
TARGET: stm32l4x.cpu - Not halted
in procedure 'reset'
in procedure 'ocd_bouncer'

I had to add -c 'reset_config none separate' for it to work for nucleo-f103rb, nucleo-l432kc. This seems weird to me (but adding this ruins the setup for other boards), I don't know why they couldn't be halted although I could see that assert_rst was being called.

I'm also unable to flash nucleo-l073rz I'm unable to halt it.

Info : The selected transport took over low-level target control. The results might differ compared to plain JTAG/SWD
none separate
srst_only separate srst_nogate srst_open_drain connect_assert_srst
srst_only separate srst_nogate srst_open_drain connect_assert_srst
Info : Unable to match requested speed 300 kHz, using 240 kHz
Info : Unable to match requested speed 300 kHz, using 240 kHz
Info : clock speed 240 kHz
Error: libusb_open() failed with LIBUSB_ERROR_ACCESS
Info : STLINK v2 JTAG v28 API v2 SWIM v17 VID 0x0483 PID 0x374B
Info : using stlink api v2
Info : Target voltage: 3.252071
Info : stm32l0.cpu: hardware has 4 breakpoints, 2 watchpoints
    TargetName         Type       Endian TapName            State       
--  ------------------ ---------- ------ ------------------ ------------
 0* stm32l0.cpu        hla_target little stm32l0.cpu        running
Info : Unable to match requested speed 300 kHz, using 240 kHz
Info : Unable to match requested speed 300 kHz, using 240 kHz
adapter speed: 240 kHz
Error: timed out while waiting for target halted
TARGET: stm32l0.cpu - Not halted
in procedure 'reset' 
in procedure 'ocd_bouncer'

fjmolinas · 2019-09-13T07:42:23Z

I had to add -c 'reset_config none separate' for it to work for nucleo-f103rb, nucleo-l432kc. This seems weird to me (but adding this ruins the setup for other boards), I don't know why they couldn't be halted although I could see that assert_rst was being called.

I need to look in to this some more, but the convenience is that if really needed we can add another optional configuration to be added to OPENOCD_EXTRA_RESET_INIT, a OPENOCD_RESET_NONE_SEPARATE. But I need to look into the issue some more, and maybe test on other nucleos, see if its a board issue or sub-family issue.

cladmi · 2019-09-20T08:44:37Z

Maybe #12261 (comment) could also help for testing this.

fjmolinas · 2019-09-20T08:47:16Z

Maybe #12261 (comment) could also help for testing this.

You mean setting pm?

cladmi · 2019-09-20T08:47:41Z

Yes.

fjmolinas · 2019-09-20T09:08:18Z

You mean setting pm?

I tried that but I'm not able to reproduce whatever state the board was in where it couldn't be flashed... I'll run all tests on CI again to see if I find the culprit.

benemorius · 2019-09-20T09:24:45Z

You mean setting pm?

I tried that but I'm not able to reproduce whatever state the board was in where it couldn't be flashed

I think that's from one of two reasons:

some mcus keep the SWD hardware powered on until the next power-on-reset any time the SWD hardware has been utilized since the last power-on-reset (efm32 does this)
some mcus don't power off the SWD hardware even in low power modes for your convenience (kinetis won't de-power SWD in pm 1 but it does in pm 0)

It's a bit of a crap shoot in that there is no standard among the variety of mcus in terms of when SWD should be powered versus not. I don't have experience with stm32 but I'd suggest power-cycling after flashing a firmware that calls pm_set(0) in case it behaves like efm32. If that doesn't do the trick, only the reference manual can say what will.

fjmolinas · 2019-09-23T07:38:12Z

I ran all tests again for the boards in issue and I didn't encounter any issues.

#### nucleo-f103rb/failuresummary.md

Failures during test:
- [tests/driver_grove_ledbar](tests/driver_grove_ledbar/test.failed)
- [tests/driver_hd44780](tests/driver_hd44780/test.failed)
- [tests/driver_my9221](tests/driver_my9221/test.failed)
- [tests/gnrc_ipv6_ext](tests/gnrc_ipv6_ext/test.failed)
- [tests/gnrc_rpl_srh](tests/gnrc_rpl_srh/test.failed)
- [tests/gnrc_sock_dns](tests/gnrc_sock_dns/test.failed)
- [tests/pkg_fatfs_vfs](tests/pkg_fatfs_vfs/test.failed)
- [tests/xtimer_periodic_wakeup](tests/xtimer_periodic_wakeup/test.failed)
- [tests/xtimer_usleep_short](tests/xtimer_usleep_short/test.failed)

#### nucleo-l073rz/failuresummary.md

Failures during compilation:
- [tests/riotboot](tests/riotboot/compilation.failed)

Failures during test:
- [tests/driver_grove_ledbar](tests/driver_grove_ledbar/test.failed)
- [tests/driver_my9221](tests/driver_my9221/test.failed)
- [tests/gnrc_ipv6_ext](tests/gnrc_ipv6_ext/test.failed)
- [tests/gnrc_rpl_srh](tests/gnrc_rpl_srh/test.failed)
- [tests/gnrc_sock_dns](tests/gnrc_sock_dns/test.failed)
- [tests/pkg_fatfs_vfs](tests/pkg_fatfs_vfs/test.failed)

#### nucleo-l432kc/failuresummary.md

Failures during compilation:
- [tests/riotboot](tests/riotboot/compilation.failed)

Failures during test:
- [tests/driver_grove_ledbar](tests/driver_grove_ledbar/test.failed)
- [tests/driver_hd44780](tests/driver_hd44780/test.failed)
- [tests/driver_my9221](tests/driver_my9221/test.failed)
- [tests/gnrc_ipv6_ext](tests/gnrc_ipv6_ext/test.failed)
- [tests/gnrc_rpl_srh](tests/gnrc_rpl_srh/test.failed)
- [tests/gnrc_sock_dns](tests/gnrc_sock_dns/test.failed)
- [tests/pkg_fatfs_vfs](tests/pkg_fatfs_vfs/test.failed)

I'm not sure what happened, It could have been an issue with my local setup. I wouldn't stall the PR because of this.

fjmolinas · 2019-09-23T07:40:50Z

For b-l072z-lrwan1:

OPENOCD_RESET_USE_CONNECT_ASSERT_SRST=0 PORT=/dev/ttyACM1 make -C tests/ssp/ BOARD=b-l072z-lrwan1 flash -j3

e: Entering directory '/home/francisco/workspace/RIOT/tests/ssp'
Building application "tests_ssp" for "b-l072z-lrwan1" with MCU "stm32l0".

"make" -C /home/francisco/workspace/RIOT/boards/b-l072z-lrwan1
"make" -C /home/francisco/workspace/RIOT/core
"make" -C /home/francisco/workspace/RIOT/cpu/stm32l0
"make" -C /home/francisco/workspace/RIOT/drivers
"make" -C /home/francisco/workspace/RIOT/cpu/cortexm_common
"make" -C /home/francisco/workspace/RIOT/drivers/periph_common
"make" -C /home/francisco/workspace/RIOT/cpu/stm32_common
"make" -C /home/francisco/workspace/RIOT/cpu/cortexm_common/periph
"make" -C /home/francisco/workspace/RIOT/cpu/stm32_common/periph
"make" -C /home/francisco/workspace/RIOT/sys
"make" -C /home/francisco/workspace/RIOT/cpu/stm32l0/periph
"make" -C /home/francisco/workspace/RIOT/sys/auto_init
"make" -C /home/francisco/workspace/RIOT/sys/newlib_syscalls_default
"make" -C /home/francisco/workspace/RIOT/sys/pm_layered
"make" -C /home/francisco/workspace/RIOT/sys/ssp
"make" -C /home/francisco/workspace/RIOT/sys/stdio_uart
   text	   data	    bss	    dec	    hex	filename
   8448	    124	   2568	  11140	   2b84	/home/francisco/workspace/RIOT/tests/ssp/bin/b-l072z-lrwan1/tests_ssp.elf
/home/francisco/workspace/RIOT/dist/tools/openocd/openocd.sh flash /home/francisco/workspace/RIOT/tests/ssp/bin/b-l072z-lrwan1/tests_ssp.elf
### Flashing Target ###
Open On-Chip Debugger 0.10.0+dev-00703-g92bb76a4-dirty (2019-07-19-14:27)
Licensed under GNU GPL v2
For bug reports, read
	http://openocd.org/doc/doxygen/bugs.html
WARNING: interface/stlink-v2-1.cfg is deprecated, please switch to interface/stlink.cfg
hla_swd
adapter speed: 300 kHz
adapter_nsrst_delay: 100
Info : The selected transport took over low-level target control. The results might differ compared to plain JTAG/SWD
none separate
srst_only separate srst_nogate srst_open_drain connect_deassert_srst
Info : clock speed 300 kHz
Info : STLINK V2J28M18 (API v2) VID:PID 0483:374B
Info : Target voltage: 3.247706
Error: init mode failed (unable to connect to the target)


/home/francisco/workspace/RIOT/tests/ssp/../../Makefile.include:556: recipe for target 'flash' failed
make: *** [flash] Error 1
make: Leaving directory '/home/francisco/workspace/RIOT/tests/ssp'

OPENOCD_RESET_USE_CONNECT_ASSERT_SRST=1 PORT=/dev/ttyACM1 make -C tests/ssp/ BOARD=b-l072z-lrwan1 flash -j3

make: Entering directory '/home/francisco/workspace/RIOT/tests/ssp'
Building application "tests_ssp" for "b-l072z-lrwan1" with MCU "stm32l0".

"make" -C /home/francisco/workspace/RIOT/boards/b-l072z-lrwan1
"make" -C /home/francisco/workspace/RIOT/core
"make" -C /home/francisco/workspace/RIOT/cpu/stm32l0
"make" -C /home/francisco/workspace/RIOT/drivers
"make" -C /home/francisco/workspace/RIOT/cpu/cortexm_common
"make" -C /home/francisco/workspace/RIOT/drivers/periph_common
"make" -C /home/francisco/workspace/RIOT/cpu/cortexm_common/periph
"make" -C /home/francisco/workspace/RIOT/cpu/stm32_common
"make" -C /home/francisco/workspace/RIOT/sys
"make" -C /home/francisco/workspace/RIOT/cpu/stm32_common/periph
"make" -C /home/francisco/workspace/RIOT/cpu/stm32l0/periph
"make" -C /home/francisco/workspace/RIOT/sys/auto_init
"make" -C /home/francisco/workspace/RIOT/sys/newlib_syscalls_default
"make" -C /home/francisco/workspace/RIOT/sys/pm_layered
"make" -C /home/francisco/workspace/RIOT/sys/ssp
"make" -C /home/francisco/workspace/RIOT/sys/stdio_uart
   text	   data	    bss	    dec	    hex	filename
   8448	    124	   2568	  11140	   2b84	/home/francisco/workspace/RIOT/tests/ssp/bin/b-l072z-lrwan1/tests_ssp.elf
/home/francisco/workspace/RIOT/dist/tools/openocd/openocd.sh flash /home/francisco/workspace/RIOT/tests/ssp/bin/b-l072z-lrwan1/tests_ssp.elf
### Flashing Target ###
Open On-Chip Debugger 0.10.0+dev-00703-g92bb76a4-dirty (2019-07-19-14:27)
Licensed under GNU GPL v2
For bug reports, read
	http://openocd.org/doc/doxygen/bugs.html
WARNING: interface/stlink-v2-1.cfg is deprecated, please switch to interface/stlink.cfg
hla_swd
adapter speed: 300 kHz
adapter_nsrst_delay: 100
Info : The selected transport took over low-level target control. The results might differ compared to plain JTAG/SWD
none separate
srst_only separate srst_nogate srst_open_drain connect_deassert_srst
srst_only separate srst_nogate srst_open_drain connect_assert_srst
Info : clock speed 300 kHz
Info : STLINK V2J28M18 (API v2) VID:PID 0483:374B
Info : Target voltage: 3.247706
Info : stm32l0.cpu: hardware has 4 breakpoints, 2 watchpoints
Info : Listening on port 42045 for gdb connections
    TargetName         Type       Endian TapName            State       
--  ------------------ ---------- ------ ------------------ ------------
 0* stm32l0.cpu        hla_target little stm32l0.cpu        reset
Info : Unable to match requested speed 300 kHz, using 240 kHz
Info : Unable to match requested speed 300 kHz, using 240 kHz
adapter speed: 240 kHz
target halted due to debug-request, current mode: Thread 
xPSR: 0xf1000000 pc: 0x0800041c msp: 0x20000200
auto erase enabled
Info : Device: STM32L0xx (Cat.5)
Info : STM32L flash has dual banks. Bank (0) size is 96kb, base address is 0x8000000
wrote 12288 bytes from file /home/francisco/workspace/RIOT/tests/ssp/bin/b-l072z-lrwan1/tests_ssp.elf in 2.838022s (4.228 KiB/s)
verified 8572 bytes in 0.454167s (18.432 KiB/s)
Info : Unable to match requested speed 300 kHz, using 240 kHz
Info : Unable to match requested speed 300 kHz, using 240 kHz
adapter speed: 240 kHz
shutdown command invoked
Done flashing

fjmolinas · 2019-09-23T07:46:10Z

I think that's from one of two reasons:

some mcus keep the SWD hardware powered on until the next power-on-reset any time the SWD hardware has been utilized since the last power-on-reset (efm32 does this)

some mcus don't power off the SWD hardware even in low power modes for your convenience (kinetis won't de-power SWD in pm 1 but it does in pm 0)

Thanks for the input @benemorius. I'm not sure this is the case here, since I'm able to flash the boards again when pm_set(0) has been called (when setting OPENOCD_RESET_USE_CONNECT_ASSERT_SRST=1).

It's a bit of a crap shoot in that there is no standard among the variety of mcus in terms of when SWD should be powered versus not. I don't have experience with stm32 but I'd suggest power-cycling after flashing a firmware that calls pm_set(0) in case it behaves like efm32. If that doesn't do the trick, only the reference manual can say what will.

This might have been the case for the 3 boards mentioned, but I haven't been able to reproduce the conditions that led to the board needing to be power-cycled to be flashed again (or needing to to set -c 'reset_config none separate').

I would not stall this PR because of this.

fjmolinas · 2019-09-23T08:03:32Z

For i-nucleo-lrwan1:

OPENOCD_RESET_USE_CONNECT_ASSERT_SRST=0 PORT=/dev/ttyACM1 make -C tests/periph_pm/ BOARD=i-nucleo-lrwan1 flash -j3

make: Entering directory '/home/francisco/workspace/RIOT/tests/periph_pm'
Building application "tests_periph_pm" for "i-nucleo-lrwan1" with MCU "stm32l0".

"make" -C /home/francisco/workspace/RIOT/boards/i-nucleo-lrwan1
"make" -C /home/francisco/workspace/RIOT/core
"make" -C /home/francisco/workspace/RIOT/cpu/stm32l0
"make" -C /home/francisco/workspace/RIOT/cpu/cortexm_common
"make" -C /home/francisco/workspace/RIOT/cpu/stm32_common
"make" -C /home/francisco/workspace/RIOT/cpu/stm32_common/periph
"make" -C /home/francisco/workspace/RIOT/drivers
"make" -C /home/francisco/workspace/RIOT/cpu/cortexm_common/periph
"make" -C /home/francisco/workspace/RIOT/cpu/stm32l0/periph
"make" -C /home/francisco/workspace/RIOT/sys
"make" -C /home/francisco/workspace/RIOT/sys/auto_init
"make" -C /home/francisco/workspace/RIOT/drivers/periph_common
"make" -C /home/francisco/workspace/RIOT/sys/isrpipe
"make" -C /home/francisco/workspace/RIOT/sys/newlib_syscalls_default
"make" -C /home/francisco/workspace/RIOT/sys/pm_layered
"make" -C /home/francisco/workspace/RIOT/sys/shell
"make" -C /home/francisco/workspace/RIOT/sys/stdio_uart
"make" -C /home/francisco/workspace/RIOT/sys/tsrb
   text	   data	    bss	    dec	    hex	filename
  19132	    240	   2668	  22040	   5618	/home/francisco/workspace/RIOT/tests/periph_pm/bin/i-nucleo-lrwan1/tests_periph_pm.elf
/home/francisco/workspace/RIOT/dist/tools/openocd/openocd.sh flash /home/francisco/workspace/RIOT/tests/periph_pm/bin/i-nucleo-lrwan1/tests_periph_pm.elf
### Flashing Target ###
Open On-Chip Debugger 0.10.0+dev-00703-g92bb76a4-dirty (2019-07-19-14:27)
Licensed under GNU GPL v2
For bug reports, read
	http://openocd.org/doc/doxygen/bugs.html
WARNING: interface/stlink-v2-1.cfg is deprecated, please switch to interface/stlink.cfg
hla_swd
adapter speed: 300 kHz
adapter_nsrst_delay: 100
Info : The selected transport took over low-level target control. The results might differ compared to plain JTAG/SWD
none separate
srst_only separate srst_nogate srst_open_drain connect_deassert_srst
Info : clock speed 300 kHz
Info : STLINK V2J28M18 (API v2) VID:PID 0483:374B
Info : Target voltage: 0.009443
Error: target voltage may be too low for reliable debugging
Error: init mode failed (unable to connect to the target)


/home/francisco/workspace/RIOT/tests/periph_pm/../../Makefile.include:556: recipe for target 'flash' failed
make: *** [flash] Error 1
make: Leaving directory '/home/francisco/workspace/RIOT/tests/periph_pm'

OPENOCD_RESET_USE_CONNECT_ASSERT_SRST=1 PORT=/dev/ttyACM1 make -C tests/periph_pm/ BOARD=i-nucleo-lrwan1 flash -j3

make: Entering directory '/home/francisco/workspace/RIOT/tests/periph_pm'
Building application "tests_periph_pm" for "i-nucleo-lrwan1" with MCU "stm32l0".

"make" -C /home/francisco/workspace/RIOT/boards/i-nucleo-lrwan1
"make" -C /home/francisco/workspace/RIOT/core
"make" -C /home/francisco/workspace/RIOT/cpu/stm32l0
"make" -C /home/francisco/workspace/RIOT/cpu/cortexm_common
"make" -C /home/francisco/workspace/RIOT/cpu/stm32_common
"make" -C /home/francisco/workspace/RIOT/cpu/stm32_common/periph
"make" -C /home/francisco/workspace/RIOT/cpu/stm32l0/periph
"make" -C /home/francisco/workspace/RIOT/cpu/cortexm_common/periph
"make" -C /home/francisco/workspace/RIOT/drivers
"make" -C /home/francisco/workspace/RIOT/sys
"make" -C /home/francisco/workspace/RIOT/drivers/periph_common
"make" -C /home/francisco/workspace/RIOT/sys/auto_init
"make" -C /home/francisco/workspace/RIOT/sys/isrpipe
"make" -C /home/francisco/workspace/RIOT/sys/newlib_syscalls_default
"make" -C /home/francisco/workspace/RIOT/sys/pm_layered
"make" -C /home/francisco/workspace/RIOT/sys/shell
"make" -C /home/francisco/workspace/RIOT/sys/stdio_uart
"make" -C /home/francisco/workspace/RIOT/sys/tsrb
   text	   data	    bss	    dec	    hex	filename
  19132	    240	   2668	  22040	   5618	/home/francisco/workspace/RIOT/tests/periph_pm/bin/i-nucleo-lrwan1/tests_periph_pm.elf
/home/francisco/workspace/RIOT/dist/tools/openocd/openocd.sh flash /home/francisco/workspace/RIOT/tests/periph_pm/bin/i-nucleo-lrwan1/tests_periph_pm.elf
### Flashing Target ###
Open On-Chip Debugger 0.10.0+dev-00703-g92bb76a4-dirty (2019-07-19-14:27)
Licensed under GNU GPL v2
For bug reports, read
	http://openocd.org/doc/doxygen/bugs.html
WARNING: interface/stlink-v2-1.cfg is deprecated, please switch to interface/stlink.cfg
hla_swd
adapter speed: 300 kHz
adapter_nsrst_delay: 100
Info : The selected transport took over low-level target control. The results might differ compared to plain JTAG/SWD
none separate
srst_only separate srst_nogate srst_open_drain connect_deassert_srst
srst_only separate srst_nogate srst_open_drain connect_assert_srst
Info : clock speed 300 kHz
Info : STLINK V2J28M18 (API v2) VID:PID 0483:374B
Info : Target voltage: 0.006295
Error: target voltage may be too low for reliable debugging
Info : stm32l0.cpu: hardware has 4 breakpoints, 2 watchpoints
Info : Listening on port 40993 for gdb connections
    TargetName         Type       Endian TapName            State       
--  ------------------ ---------- ------ ------------------ ------------
 0* stm32l0.cpu        hla_target little stm32l0.cpu        reset
Info : Unable to match requested speed 300 kHz, using 240 kHz
Info : Unable to match requested speed 300 kHz, using 240 kHz
adapter speed: 240 kHz
target halted due to debug-request, current mode: Thread 
xPSR: 0xf1000000 pc: 0x0800041c msp: 0x20000200
auto erase enabled
Info : Device: STM32L0xx (Cat. 3)
Info : STM32L flash size is 64kb, base address is 0x8000000
wrote 20480 bytes from file /home/francisco/workspace/RIOT/tests/periph_pm/bin/i-nucleo-lrwan1/tests_periph_pm.elf in 4.731254s (4.227 KiB/s)
verified 19372 bytes in 0.860250s (21.991 KiB/s)
Info : Unable to match requested speed 300 kHz, using 240 kHz
Info : Unable to match requested speed 300 kHz, using 240 kHz
adapter speed: 240 kHz
shutdown command invoked
Done flashing
make: Leaving directory '/home/francisco/workspace/RIOT/tests/periph_pm'

fjmolinas

Changes look good, it was a required clean-up after #11976. I tested on one member of each stm32x family we support and on b-l072z-lrwan1 and i-nucleo-lrwan1. ACK, on my side.

aabadie · 2019-09-23T12:01:26Z

@fjmolinas, thanks for testing this in depth. Are we good to go here ?

fjmolinas · 2019-09-23T12:02:35Z

@fjmolinas, thanks for testing this in depth. Are we good to go here ?

Yep lets go with this one.

aabadie · 2019-09-23T12:03:59Z

Thank you!

cladmi · 2019-09-23T13:28:41Z

For further reference, if somebody has an issue on his board after this PR, just do a PR adding OPENOCD_RESET_USE_CONNECT_ASSERT_SRST ?= 0 in the board Makefile.include before including the common/nucleo/Makefile.include to restore the previous behavior :)

aabadie added 4 commits September 2, 2019 21:44

boards/nucleo: generalize use of connect_assert_srst for flashing

fc923ba

This allows to flash/reset even over a crashed or sleeping firmware

boards/nucleo-f091rc: remove duplicate use of connect_assert_srst

01642b9

boards/stm32: remove use of connect_assert_srst for flashing stm32l0

281273f

boards/stm32l0: use connect_assert_srst when flashing

e45388e

aabadie added the Area: boards Area: Board ports label Sep 3, 2019

aabadie requested a review from fjmolinas September 3, 2019 06:26

aabadie added the CI: ready for build If set, CI server will compile all applications for all available boards for the labeled PR label Sep 3, 2019

fjmolinas mentioned this pull request Sep 19, 2019

boards/frdm: fix flashing from invalid state #12261

Merged

fjmolinas added the Reviewed: 3-testing The PR was tested according to the maintainer guidelines label Sep 23, 2019

fjmolinas approved these changes Sep 23, 2019

View reviewed changes

fjmolinas merged commit 8467dba into RIOT-OS:master Sep 23, 2019

aabadie deleted the pr/boards/stm32_connect_assert_srst branch September 23, 2019 12:03

kb2ma added this to the Release 2019.10 milestone Sep 29, 2019

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

boards/stm32: generalize use of connect_assert_srst for flashing #12158

boards/stm32: generalize use of connect_assert_srst for flashing #12158

aabadie commented Sep 3, 2019 •

edited

Loading

fjmolinas commented Sep 10, 2019

fjmolinas commented Sep 13, 2019

fjmolinas commented Sep 13, 2019

cladmi commented Sep 20, 2019

fjmolinas commented Sep 20, 2019

cladmi commented Sep 20, 2019

fjmolinas commented Sep 20, 2019

benemorius commented Sep 20, 2019

fjmolinas commented Sep 23, 2019

fjmolinas commented Sep 23, 2019

fjmolinas commented Sep 23, 2019

fjmolinas commented Sep 23, 2019

fjmolinas left a comment

aabadie commented Sep 23, 2019

fjmolinas commented Sep 23, 2019

aabadie commented Sep 23, 2019

cladmi commented Sep 23, 2019

boards/stm32: generalize use of connect_assert_srst for flashing #12158

boards/stm32: generalize use of connect_assert_srst for flashing #12158

Conversation

aabadie commented Sep 3, 2019 • edited Loading

Contribution description

Testing procedure

Issues/PRs references

fjmolinas commented Sep 10, 2019

fjmolinas commented Sep 13, 2019

fjmolinas commented Sep 13, 2019

cladmi commented Sep 20, 2019

fjmolinas commented Sep 20, 2019

cladmi commented Sep 20, 2019

fjmolinas commented Sep 20, 2019

benemorius commented Sep 20, 2019

fjmolinas commented Sep 23, 2019

fjmolinas commented Sep 23, 2019

fjmolinas commented Sep 23, 2019

fjmolinas commented Sep 23, 2019

fjmolinas left a comment

Choose a reason for hiding this comment

aabadie commented Sep 23, 2019

fjmolinas commented Sep 23, 2019

aabadie commented Sep 23, 2019

cladmi commented Sep 23, 2019

aabadie commented Sep 3, 2019 •

edited

Loading