-
Notifications
You must be signed in to change notification settings - Fork 1.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Fixed some flashing issues on STM32L0 #1330
Merged
Nightwalker-87
merged 2 commits into
stlink-org:develop
from
andars:fix-some-stm32l0-flashing-issues
Sep 1, 2023
Merged
Fixed some flashing issues on STM32L0 #1330
Nightwalker-87
merged 2 commits into
stlink-org:develop
from
andars:fix-some-stm32l0-flashing-issues
Sep 1, 2023
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
stm32l1_write_half_pages uses a local flash_loader_t that is never initialized. This results in stlink_flash_loader_run using uninitialized values for fl->buf_addr and fl->loader_addr when copying the buffer and initializing the source register and PC before running the core to execute the flashloader. Pass the flash_loader_t from stlink_flashloader_write through to stm32l1_write_half_pages and use that one instead of an uninitialized local structure.
STM32L0 chips use loader_code_stm32lx, but this flash loader is built for armv7-m and uses instructions that are unsupported on STM32L0 (which have Cortex M0+ cores implementing armv6-m). In particular, loader_code_stm32lx uses variants of add-immediate that do not update the condition flags ( `add r0, r0, stlink-org#4` ). These are 32bit instructions in armv7-m and are not available in armv6-m. Enable loader_code_stm32lx to run on both armv6-m and armv7-m by building for armv6-m, which requires changing the `add` instructions to `adds` instructions that do update condition flags (which is ok because the subs updates the condition flags again before the branch).
Nightwalker-87
approved these changes
Aug 27, 2023
Nightwalker-87
moved this from Reviewer approved
to Review in progress
in Release v1.8.0
Aug 27, 2023
Now we need to identify the related issues that are addressed by this fix. |
Nightwalker-87
changed the title
Fix some flashing issues on STM32L0
Fixed some flashing issues on STM32L0
Aug 27, 2023
Ant-ON
approved these changes
Aug 28, 2023
@Nightwalker-87 I think this most likely should fix #1203, #1289, #1253 |
Nightwalker-87
added
status/resolved
component/stlink-lib
and removed
needs/investigation
needs/testing
labels
Aug 28, 2023
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Hi,
While trying to use st-link to flash a STM32L051 on a custom board, the flash loader fails in
stm32l1_write_half_pages
, and the fallback path usually reports "Flash memory contains a non-erased value" (but still successfully writes the flash since the NOTZEROERR doesn't prevent the write on this category 3 device - 3.3.4 RM0377). Sost-flash write
does write the flash but reports failure, andload
in gdb usingst-util
server reportsError finishing flash operation
.I found two issues in the flashing code:
stm32l1_write_half_pages
callsstlink_flash_loader_run
with a localflash_loader_t
struct that is never initialized, so the loader is run using uninitialized values for the loader code base address and the SRAM buffer addressloader_code_stm32lx
is used for both STM32L0 devices with armv6-m cores and STM32L1 devices with armv7-m, but it usesadd
instructions that are only supported in armv7-m, so when loader code runs it writes one word to flash and then faults on theadd
.With these issues fixed, flashing works without error on this device.
This is related to the various reported issues about failures flashing STM32Lx devices (e.g. in #681) and probably helps fix some of those, but I don't have other hardware to test on to confirm if this improves things on devices other than STM32L051. Based on the code history these 2 bugs seem to be introduced more recently than some of the early reported issues, so there may be some remaining issues too.
It seems like the current flashloader implementation in
stm32l1_write_half_pages
maybe doesn't have much advantage over the fallback path usingstlink_write_mem32
since both wait for flash programming to complete from the host system every halfpage, but these 2 commits make this path work for now on in my testing on STM32L051( in the future it can potentially be enhanced to poll on
FLASH_SR_BSY
every halfpage from the device instead of the host or removed if not useful)(Closes #681) (Closes #1203) (Closes #1225) (Closes #1253) (Closes #1289)