Skip to content
New issue

Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.

#

By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? # to your account

Jump to bottom

Self bricking when uploading large payload #1

Closed
perillamint opened this issue Aug 18, 2017 · 3 comments
Closed

Self bricking when uploading large payload #1

perillamint opened this issue Aug 18, 2017 · 3 comments

Comments

@perillamint
Copy link

Hello, while I porting DAPBoot on TS100 soldering iron, I discovered this problems:

  • When I try to flash large binary, even it is larger then flash size of STM32, it doesn't fail.
  • Flashing large enough binary could brick bootloader itself.

To mitigate this problem, I patched DAPBoot like this: eDesignOSS@e3a5a63

Before making PR with this patch, I want to hear some comments about this patch.

Thanks.
devanlai added a commit that referenced this issue Aug 18, 2017
@devanlai
Add FLASH_SIZE_OVERRIDE to override flash size on 64KiB parts
a2cf981 
Many 64KiB STM32F103C8 parts unofficially have 128KiB flash anyways.
Add support for explicitly recognizing the effective flash size we're
willing to work with by allowing targets to set the flash size with
FLASH_SIZE_OVERRIDE, which overrides the flash size in bytes.

Previously, download sizes were not checked (see issue #1), but upload
sizes were, so applications would've been limited to 56KiB when reading
back the firmware.

All existing configurations except for the Maple Mini (which has a real
128KiB part anyways) now set FLASH_SIZE_OVERRIDE to 128KiB.
devanlai added a commit that referenced this issue Aug 18, 2017
@devanlai
Prevent writing past the end of flash
cd4c37f 
Fixes issue #1 by making target_flash_program_array() test against the
end of the flash address space, as proposed by @perillamint
@devanlai
Copy link
Owner

Hi perillamint,
Thanks for reporting this issue. I agree that the bootloader should prevent the user from writing too far into flash, especially if could wrap around and overwrite the bootloader.

Your patch looks sound to me. I've done some refactoring so that the flash size is a little better defined across all targets. I've pushed a tentative branch here:
https://github.com/devanlai/dapboot/compare/prevent-flash-overrun

If you want to try it out, as far as I can tell, it should merge cleanly apart from the functionally equivalent changes in target_flash_program_array()

@perillamint
Copy link
Author

Thanks for fix. I think your refactoring much looks cleaner then my "quick n dirty" solution. 👍

@devanlai
Copy link
Owner

Great, I've merged the fixes to master.

# for free to join this conversation on GitHub. Already have an account? # to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@devanlai @perillamint