Add support for optional SD Card programming#131
Open
Arksine wants to merge 17 commits into
Open
Conversation
Arksine
force-pushed
the
dev-sdcard-20220519
branch
2 times, most recently
from
23563e5 to
ac9edd6
Compare
Arksine
force-pushed
the
dev-sdcard-20220519
branch
from
ac9edd6 to
4ef867a
Compare
|
What is the state of this PR? This feature would be very useful. |
Signed-off-by: Eric Callahan <arksine.code@gmail.com>
Signed-off-by: Eric Callahan <arksine.code@gmail.com>
Signed-off-by: Eric Callahan <arksine.code@gmail.com>
- 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 <arksine.code@gmail.com>
This contains a port of Klipper's spi_software implementation for use with CanBoot's sdcard. Signed-off-by: Eric Callahan <arksine.code@gmail.com>
This allows local flashing to update transfer state. Signed-off-by: Eric Callahan <arksine.code@gmail.com>
Signed-off-by: Eric Callahan <arksine.code@gmail.com>
Signed-off-by: Eric Callahan <arksine.code@gmail.com>
Add support for firmware uploads from an SD Card via SPI. Signed-off-by: Eric Callahan <arksine.code@gmail.com>
Signed-off-by: Eric Callahan <arksine.code@gmail.com>
Signed-off-by: Eric Callahan <arksine.code@gmail.com>
When an error is detected during the programming procedure enter command mode. Signed-off-by: Eric Callahan <arksine.code@gmail.com>
Signed-off-by: Eric Callahan <arksine.code@gmail.com>
Signed-off-by: Eric Callahan <arksine.code@gmail.com>
Syncrhonize SD Card flag values between SPI and SDIO modes. Signed-off-by: Eric Callahan <arksine.code@gmail.com>
Signed-off-by: Eric Callahan <arksine.code@gmail.com>
Signed-off-by: Eric Callahan <arksine.code@gmail.com>
Arksine
force-pushed
the
dev-sdcard-20220519
branch
from
4ef867a to
3dfe4d0
Compare
Owner
Author
|
@VinnyCordeiro Good question. I recently rebased against the rp2xxx changes and at least the rp2040 still seems to work. I don't have a rp2350 to test. I pushed this branch to gauge interest in this feature, with the hope that several individuals would volunteer for testing. This addition may require significant maintenance, and I don't want to merge it if:
I didn't announce this PR, so perhaps no one (but you) has noticed it. I'll see about doing so, in the meantime I'll leave it here for further feedback. Edit: FWIW, I did cherry pick most of the changes to |
This file contains hidden or 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
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
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.