I recently got SDIO flashsd working on my Tronxy Chitu v6 board, and looking at the flashsd configs, it appears there are likely several other STM32 based mainboards that could have similar support configured for them.
The original SDIO enablement was done by Gregor Molter, but it was only left for STM32F4 mcus, whilst others like the f103, h7 etc also support SDIO, and I think would be relatively easy to add.
However… I don’t have any of these boards to test with.
Does anyone have any of these boards, and willing to test if I put together a PR for SDIO for them?
The exact board list is:
btt-octopus-f407-v1
btt-octopus-f429-v1
btt-octopus-f446-v1
btt-skr-3-h743
btt-skr-3-h723
creality-v4.2.2
The following PR should already work for the creality-v4.2.2 if the same board-defs.py change is made to configure sdio as I’ve done for the chitu-v6
The btt-octopus boards should also work under the same PR (perhaps even before) with a similar change in board_defs.py to enable sdio.
The schematic for each tells all about the stock bootloader. If the SD card slot doesn’t have the connections to support anything other than SDIO or PR, then modding the main board or adding an off-board SD card interface may be required.
I have never needed this feature on my BTT boards so I don’t know the specifics.
Not sure what your reply is about.
Do you have one of the boards listed?
Do you use flashsd to update Klipper on it?
Are you willing to test a PR for me that would hopefully allow use of SDIO to do this?
If the answer to any of these questions is ‘no’, then I would not have expected you to post anything in response to my topic.
I was a long-time BTT user and was sent many boards to evaluate.
I have the following boards that use an SD card. Most don’t have the stock bootloader, and I do use Klipper on most. I have also created many guides for Klipper setup and installs on these boards, along with CAN bus setups.
BTT SKR 1.4
BTT SKR Pro
BTT GTR / M5
BTT Octopus
BTT Octopus Pro
BTT SKR3
BTT SKR3 EZ
BTT Manta M8P V1.0
I may have others but they are stored away.
I can do some PR testing (just as a board with an LCD) in my free time before my next out-of-state trip.
FYI, I am the admin who started the private FB group for Octopus board owners; there are a few BTT company members and 2.3K plus other members. Redirecting...
Can you explain why you’re doing this? I’m really asking what are the advantages of using SDIO for Flashing the MCU when there are pretty good options available.
My understanding is that SDIO gives you faster data transfers between an SD Card and the host as well as providing some hardware interfacing options but, again, I’m not sure what are the reasons you’re looking for using it in a 3D printer running Klipper.
@mykepredko Where stock bootloader uses SDIO, it requires a physical power cycle to update firmware (via stock bootloader) if NOT using SDIO to write to the sdcard.
Just look at the boards with verify: false
If they use SDIO for sdcard write in Klipper, no need for physical power cycle.
If either of these have the f4xx series mcu on them, i.e. work with:
btt-octopus-f407-v1,
btt-octopus-f429-v1, or
btt-octopus-f446-v1 configuration
It would be appreciated if you could try out the flashsd with this klipper fork.
You’d need to be running the stock bootloader on it.
Have klipper installed on the mcu already (any v0.12+ version should suffice as the base)
Then do the ‘normal’ sequence to update the firmware using flashsd
make menuconfig
make
sudo service klipper stop
|ensure valid SD card is installed in mainboard|
./scripts/flashsd.sh {serial path to mcu} {mcu board def name}
Expected behaviour is:
mcu resets into flashsd mode
writes image to sd
verifies image on sd
reboots mcu, bootloader updates firmware, and reboots mcu again
verifies booted firmware version matches
job done.
There should be no need for you to power cycle the board, or separately play with the sd card itself to get the firmware updated.
It would be appreciated if you could try out the flashsd with this klipper fork.
I’ve updated the branch with code for the F7/H7/L4 mcus now. Although I’m pretty convinced my #ifdef action for the SDMMC ‘branching’ isn’t quite working… there must be some extra C foo going on which is interfering.
EDIT: It was all working, just VSCode not colouring things right, gcc with -E told me all was well.
Wonderful.
If you could test the process as I mentioned earlier and report back any issues that would be great.
There’s still some code tidyup that I need to do around the STM32F103 implementation, but that shouldn’t impact on the other platforms.