Add support for optional SD Card programming #131
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
Arksine
force-pushed
the
dev-sdcard-20220519
branch
2 times, most recently
from
23563e5 to
ac9edd6
Compare
Signed-off-by: Eric Callahan <[email protected]>
Signed-off-by: Eric Callahan <[email protected]>
Signed-off-by: Eric Callahan <[email protected]>
- Allow 16-bit SPI length requests. - Add spi_set_rate method. These additions accommodate the requirements for SD Card operations. Signed-off-by: Eric Callahan <[email protected]>
This contains a port of Klipper's spi_software implementation for use with CanBoot's sdcard. Signed-off-by: Eric Callahan <[email protected]>
This allows local flashing to update transfer state. Signed-off-by: Eric Callahan <[email protected]>
Signed-off-by: Eric Callahan <[email protected]>
Signed-off-by: Eric Callahan <[email protected]>
Add support for firmware uploads from an SD Card via SPI. Signed-off-by: Eric Callahan <[email protected]>
Signed-off-by: Eric Callahan <[email protected]>
Signed-off-by: Eric Callahan <[email protected]>
Signed-off-by: Eric Callahan <[email protected]>
Signed-off-by: Eric Callahan <[email protected]>
Signed-off-by: Eric Callahan <[email protected]>
Signed-off-by: Eric Callahan <[email protected]>
When an error is detected during the programming procedure enter command mode. Signed-off-by: Eric Callahan <[email protected]>
Signed-off-by: Eric Callahan <[email protected]>
Signed-off-by: Eric Callahan <[email protected]>
Syncrhonize SD Card flag values between SPI and SDIO modes. Signed-off-by: Eric Callahan <[email protected]>
Signed-off-by: Eric Callahan <[email protected]>
Signed-off-by: Eric Callahan <[email protected]>
Arksine
force-pushed
the
dev-sdcard-20220519
branch
from
ac9edd6 to
4ef867a
Compare
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.
This PR adds support for SD Card firmware programming in addition to the primary programming interface (ie: CANBus, USB, UART). Currently Katapult can be configured to use Hardware SPI and Software SPI for all supported MCUs. SDIO is supported exclusively for STM32F4 series MCUs. I recognize that there are printer boards that ship with STM32F1 and SMT32H7 series MCUs connected via SDIO, and will consider adding future support for those variants.
The primary motivation behind adding support is two fold. First, it provides a way to program the MCU when the primary interface is not available or not working. Second, many users have expressed a desire to switch to Katapult, however they do not want to lose SD Card programming offered by stock bootloaders.
The readme details how SD Card programming works, but I do want to note the major difference between Katapult and "stock" bootloaders. Katapult does not initialize the SD Card and check for a new firmware file on every reset. It only checks after bootloader entry, either via user request (double reset, button) or when the application area is empty. There are multple reasons why Katapult does this:
Initializing the SD Card can take time, in some cases several hundred milliseconds. Katapult seeks to minimize the reset delay. In addition, this delay can interfere with Katapult's double reset functionality.
During normal operation applications that use the SD Card will receive it in a pristine power on state. Even though Katapult makes every effort to return the SD Card to its original state before exiting, one of Katapult's goals is to launch the application as if the bootloader is not present....that is, all registers and peripherals are in their default power on state.
I have done quite a bit of local testing, however more testing would be welcomed.
In addition to SD Card support, this PR contains some changes to
flashtool.pythat have been previously requested.-roption can be used to exit before programming if that is desired.-roption also works with UART devices. It isn't possible to detect whether or not a UART device is running Klipper, so the bootloader request cannot be automated prior to programming.flashtool.pyisklipper.bin, the tool will attempt to extract Klipper's data dictionary from the binary. If the dictionary contains an MCU variant that differs from the variant reported by Katapult, then a warning is printed to the console. Katapult will not abort the upload, but the user can use this information to build and flash the correct variant if necessary.