Flash SD card (new mcu FW) & unrealized board reset

General Discussion
1

Hi,
I have BTT SKR2 board and I’d like to have working SD flash for firmware update.
As board_defs.py doesn’t contain settings for SKR-2, I added this (based on schema of this board):

diff --git a/scripts/spi_flash/board_defs.py b/scripts/spi_flash/board_defs.py
index 68385f04..ab16c437 100644
--- a/scripts/spi_flash/board_defs.py
+++ b/scripts/spi_flash/board_defs.py
@@ -55,6 +55,12 @@ BOARD_DEFS = {
         'spi_bus': "spi1",
         "cs_pin": "PA4",
         "current_firmware_path": "OLD.BIN"
+    },
+    'btt-skr-2': {
+        'mcu': "stm32f407xx",
+        'spi_bus': "swspi",
+        'spi_pins': "PC8,PD2,PC12",
+        'cs_pin': "PC11"
     }
 }

Which makes working at least to this state:

pi@fluiddpi:~/klipper $ ./scripts/flash-sdcard.sh /dev/serial/by-id/usb-Klipper_stm32f407xx_2B0023000247393439313338-if00 btt-skr-2
Flashing /home/pi/klipper/out/klipper.bin to /dev/serial/by-id/usb-Klipper_stm32f407xx_2B0023000247393439313338-if00
Checking FatFS CFFI Build...
Connecting to MCU...Connected
Checking Current MCU Configuration...Done
MCU needs restart: is_config=1, is_shutdown=0
Attempting MCU Reset...Done
Waiting for device to reconnect....Done
Connecting to MCU...Connected
Initializing SD Card and Mounting file system...

SD Card Information:
Version: 2.0
SDHC/SDXC: True
Write Protected: False
Sectors: 62333952
manufacturer_id: 3
oem_id: SD
product_name: SL32G
product_revision: 8.128
serial_number: ECAEE005
manufacturing_date: 1/2019
capacity: 29.7 GiB
fs_type: FAT32
volume_label: ENDER
volume_serial: 1081870871
Uploading Klipper Firmware to SD Card...Done
Validating Upload...Done
Firmware Upload Complete: firmware.bin, Size: 22328, Checksum (SHA1): 34545302815A304DC43B8A1AFE60146C95E9E0EB
Attempting MCU Reset...Done
Waiting for device to reconnect....Done
Connecting to MCU...Connected
Verifying Flash...
SD Card Flash Error: Version Mismatch: Got 'v0.9.1-628-gb4fec850-dirty-20210724_232904-fluiddpi...', expected 'v0.9.1-629-g0075b290-dirty-20210724_233606-fluiddpi...'
Traceback (most recent call last):
  File "/home/pi/klipper/scripts/spi_flash/spi_flash.py", line 1159, in main
    spiflash.run()
  File "/home/pi/klipper/scripts/spi_flash/spi_flash.py", line 1113, in run
    self.run_reactor_task(self.run_verify)
  File "/home/pi/klipper/scripts/spi_flash/spi_flash.py", line 1095, in run_reactor_task
    k_reactor.run()
  File "/home/pi/klipper/klippy/reactor.py", line 269, in run
    g_next.switch()
  File "/home/pi/klipper/klippy/reactor.py", line 310, in _dispatch_loop
    timeout = self._check_timers(eventtime, busy)
  File "/home/pi/klipper/klippy/reactor.py", line 156, in _check_timers
    t.waketime = waketime = t.callback(eventtime)
  File "/home/pi/klipper/klippy/reactor.py", line 48, in invoke
    res = self.callback(eventtime)
  File "/home/pi/klipper/scripts/spi_flash/spi_flash.py", line 1084, in run_verify
    self.new_dictionary)
  File "/home/pi/klipper/scripts/spi_flash/spi_flash.py", line 966, in verify_flash
    json.loads(req_dictionary)['version']))
SPIFlashError: Version Mismatch: Got 'v0.9.1-628-gb4fec850-dirty-20210724_232904-fluiddpi...', expected 'v0.9.1-629-g0075b290-dirty-20210724_233606-fluiddpi...'

Uploaded firmware.bin is OK (md5sums matches), the only thing which didn’t happened is … actual board reset :frowning:.

When I reset the board manually (or even by “FIRMWARE_RESTART”, I think), FW is flashed (and renamed fo “firmware.cur”).

So, there must be something wrong with reset function in flash-sdcard.sh ( spi_flash.py).

But this is beyond my ability and because of that I’m not even sure whether I shoud place pull request with SKR2 definition for board_defs.py (because without working reset, it is useless).

I write it here, because I’m really not sure whether spi_flash.py “reset” doesn’t work for any board (it worked in time when I had SKR Mini E3 v2.0, few(?) months ago) or just SKR-2.

2

I guess @Arksine is the authority to support → Humble ping :slight_smile:

3

I would looove to see this functionality, even if I have to do a manual FIRMWARE_RESTART afterwards! I upgraded the firmware on mine and had to swap SD cards like an animal. (I also had to put a jumper on the v0 display, which is very :confused:)

4

Shall I contact him or his mentioning here is enough?

5

Looks like he last popped in here about 10 days ago. But what you’ve got looks sufficient (to me) for the start of a pull request, and the remaining issue can be worked out there.

6

Done Add SKR2 board support for SD flash by kmarty · Pull Request #4530 · KevinOConnor/klipper · GitHub

I double checked the reset behaviour and neither spi_flash.py nor “FIRMWARE_RESTART” does the “cold” restart (board didn’t boot through bootloader/firmware flasher). It does some kind of restart(?) because the board’s USB port is disconnected and reconnected, but it is not sufficient. At this moment only reset button or power cycle works.

1 Like
7

FWIW, as I understand it, some boards use an “SDIO” mechanism for reading/writing to the sd cards. In this case, Klipper can read/write to the card, but it is not possible for the bootloader to then access the card until a manual power reset occurs. There is no known way to to automatically reset the card.

-Kevin

8

I’ve stumbled upon this topic as I too have the need to flash this board (SD card is inaccessible) so the ability to flash it via SSH (even though a power cycle is required) has been an total life-saver so the config here has been appreciated.

Sadly, the PR here Add SKR2 board support for SD flash by kmarty · Pull Request #4530 · Klipper3d/klipper · GitHub was rejected because it has for me created something of an issue. I’ve had to locally change the board_defs.py file to be able to write to the SD card, but makes Fluidd report the local klipper git version as dirty and has to be recovered to allow future updates.

Is there either a git command I can run to keep my local file copy but ensure future updates via git are successful via fluidd, OR, is there a compromise in the PR where the interactive option is renamed/adjusted to remove any confusion, but still allow the SKR v2 board (possibly others) to still use the command which is extremely valuable?

Thanks,