boards/stm32f3discovery: fix openocd config to flash from invalid state#11550
Conversation
cladmi
added
Type: bug
|
@aabadie I think you may have more insight on this, how to do a failing test and what should be changed in general. It would be nice to add a testable firmware to show it must be fixed in general. |
cladmi
changed the title
|
If it is any help I have a commit and firmware (though it is for the nucleo-l073rz, maybe it would also work for your board) documented in #10343. |
|
@MrKevinWeiss unfortunately it does not make it non flashable |
|
I mean, it isn't the worst thing if we can't break the board 😄 |
It only breaks the flasher configuration, not the board :) |
cladmi
force-pushed
the
pr/stm32f3discovery/fix_flashing
branch
from
3a18eaa to
81f6323
Compare
|
Now depending on #11976 |
cladmi
changed the title
cladmi
force-pushed
the
pr/stm32f3discovery/fix_flashing
branch
2 times, most recently
from
e579f97 to
1f6f008
Compare
|
Rebased and kept only the update after #11976 was merged |
aabadie
added
CI: ready for build
aabadie
removed
the
State: WIP
aabadie
left a comment
aabadie
left a comment
There was a problem hiding this comment.
Tested this PR and couldn't find any obvious regression. My main problem with testing is to find a firmware that avoid reflashing the board after. I tried to toggle the CPU to deep sleep, but OpenOCD is still able to reflash.
In any case, the changes strengthen the actual configuration. So ACK
Please fix the minor typo reported and squash directly.
| DEBUG_ADAPTER ?= stlink | ||
| STLINK_VERSION ?= 2 | ||
|
|
||
| # The board can become un-flashable after a some execution, |
There was a problem hiding this comment.
s/after a some execution/after some execution/
Somehow I think it would need to be a firmware that does it, or a hardfault as it was for the Because if openocd resets the board, and manages to start writing before it hardfaults or sleep, it would work. |
When flashing some applications the flasher sometimes gets stuck which prevents flashing after. It may be from a specific firmware or operation but do not have one yet. Connect with reset asserted fix flashing from this state. It was found after the `stm32f3discovery` get stuck in a non-flashable mode after some firmwares.
cladmi
force-pushed
the
pr/stm32f3discovery/fix_flashing
branch
from
f5bafa0 to
f5f275b
Compare
|
Typo fixed and squashed. |
aabadie
left a comment
aabadie
left a comment
There was a problem hiding this comment.
ACK and go (when Murdock is ready ;) )
|
Thank you for the review. |
5 participants
Contribution description
When flashing some applications the flasher sometimes gets stuck which
prevents flashing after.
It may be from a specific firmware or operation but do not have one yet.
Connect with reset asserted fix flashing from this state.
It was found after the
stm32f3discoveryget stuck in a non-flashable modeafter some firmwares.
Testing procedure
TODO: find a firmware that prevents re-flashing it
Flashing still works.
It should also fix flashing from invalid state but I do not know any way of re-creating it.
Issues/PRs references
Found while running the test suite on the board in #10870
Depends on #11976