Feature/electron/bl dfu err propagation #813
Merged
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
FIRM-303 solved. Because of a typo in flash_mal.c 5fafd11 All addresses were being converted to sector0 and the bootloader was unprotected temporarily until the system parts could be ran and sectors 0, 5, 6, 7 would be re-protected. https://github.com/spark/firmware/blob/develop/platform/MCU/STM32F2xx/STM32_USB_Device_Driver/src/usbd_flash_if.c#L101-L102 Erases were pointing to the correct sector, but silently failing. Writes were pointing to the correct sector, but also silently failing. This commit propagates the DFU erase and write errors back to the host machine. To test, erase electron completely and flash new bootloader compiled with `make clean all PLATFORM_ID=10 -s COMPILE_LTO=n` Write protect sectors 0, 5, 6 & 7. Attempt to flash system-part1.bin and system-part2.bin. They should flash fine, but don't be alarmed if you see errors. I found that when I had my antenna plugged in and battery removed, the modem would try to connect to the tower while I was DFU'ing new firmware and sometimes the noise would be enough to cause a failure. Disconnecting my antenna and also plugging in the battery kept the modem from attempting to connect to the network, and ultimately proved to have many error-free DFU transfers. Soft powering down the electron first also seems to work well. Double tap the SETUP button to completely power off the modem and STM32 processor. Hold SETUP and tap RESET until the RGB blinks yellow for DFU mode. Additional notes: * After making USB DFU errors more visible, it's clear that we need to retry the erase and write operations to improve the success rate when antennas are attached and modem is communicating with the tower. * A verification scheme was discussed as well, however this will add much more time to the DFU transfer even if no errors occur. * OTA Updates and USB DFU transfers could be made more robust by ensuring that the modem is in a low power state (not necessarily off) while copying the OTA update to memory. * The bootloader is close to the max limit of 16384 bytes and will surely go over with more retry logic added. With COMPILE_LTO=y, the new bootloader worked just as well during testing as with COMPILE_LTO=n.
# Conflicts: # platform/MCU/STM32F2xx/STM32_USB_Device_Driver/src/usbd_dfu_core.c
|
looks good. 👍 |
m-mcgowan
added a commit
that referenced
this pull request
Jan 15, 2016
…ation Feature/electron/bl dfu err propagation
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
creating a PR from @technobly's fix so I can review + merge