Flashing over "pure" serial connection (Creality 4.2.7 board)?

[DrKlipper]

Hi ! Just installed Katapult on a Creality 4.2.7 board with the deployment method. This worked for me.

I triedy to flash Klipper and I hoped to use this call for that: ~/katapult/scripts/flashtool.py -d /dev/ttyUSB0 -f ~/klipper/out/klipper.bin -b 250000 -v

But I got only this output:

Attempting to connect to bootloader
INFO:root:Response for command CONNECT timed out, 4 tries remaining
INFO:root:Response for command CONNECT timed out, 3 tries remaining
INFO:root:Response for command CONNECT timed out, 2 tries remaining
INFO:root:Response for command CONNECT timed out, 1 tries remaining
INFO:root:Response for command CONNECT timed out, 0 tries remaining
INFO:root:Response for command COMPLETE timed out, 4 tries remaining
INFO:root:Response for command COMPLETE timed out, 3 tries remaining
INFO:root:Response for command COMPLETE timed out, 2 tries remaining
INFO:root:Response for command COMPLETE timed out, 1 tries remaining
INFO:root:Response for command COMPLETE timed out, 0 tries remaining
ERROR:root:Flash Error

Even if I Reset the board twice very quickly it´s not possible to flash Klipper.

The Creality board uses a CH340 chip as USB/serial bridge.

I hope anyone can help with these questions:

• Is there any way to check if Kataput runs properbly? If you have a direct USB connection you can have a look at dmesg. But with a pure serial connection this is not possible because it just reports "CH340 device" ...
• Should it be generally possible to flash Klipper like mentioned above?

Dominik

[Arksine]

To answer your second question, yes, it is possible for Katapult to flash Klipper over Serial, provided you configured Katapult correctly. If you chose USB as the communication interface then it will fail, since the MCU is connected to the CH340 via the UART. It is necessary to select the Serial option with the correct pins connected to the CH340 (looks like PA9/PA10 according to the schematic).

If you flashed with the USB option configured you'll need to use a programmer to recover. The schematic shows that the debug pins are available, however it looks like you might need to solder your own headers.

With regard to the first question, there is an LED configuration that is intended to notify users when Katapult is running and when it is flashing. I'm not sure if the Creality 4.2.7 has any onboard LEDs, don't see any on the schematic.

[DrKlipper]

I selected serial as com interface:

    Micro-controller Architecture (STMicroelectronics STM32)  --->
    Processor model (STM32F103)  --->
[ ] Only 10KiB of RAM (for rare stm32f103x6 variant)
[ ] Disable SWD at startup (for GigaDevice stm32f103 clones)
    Build Katapult deployment application (28KiB bootloader)  --->
    Clock Reference (8 MHz crystal)  --->
    Communication interface (Serial (on USART1 PA10/PA9))  --->
    Application start offset (8KiB offset)  --->
(250000) Baud rate for serial port
()  GPIO pins to set on bootloader entry
[*] Support bootloader entry on rapid double click of reset button
[ ] Enable bootloader entry on button (or gpio) state
[ ] Enable Status LED

But no luck to flash Klipper afterward.

About the LEDs ... There are only two LEDs - Rx and Power. No extra Led on any other µC Pin sadly.

Any other ideas what I could check / test to get katapult working?

[Arksine]

Any other ideas what I could check / test to get katapult working?

Unfortunately I don't have much more guidance to give. I would check to make sure the deployer flashed by attempting to flash Klipper via SD. Once you have verified that the stock bootloader is indeed not functional the next step is to attempt to program Katapult directly.

One other thing, I presume that this board is a legit STM32F103, and not one of the GD32 clones? I know that Creality has released boards with both on the 4.2.2, but not sure about the 4.2.7.

[DrKlipper]

Once you have verified that the stock bootloader is indeed not functional the next step is to attempt to program Katapult directly.

Oh, maybe you got me wrong. The stock bootloader works fine. It flashes Katapult over SD without any issue. Even flashing Klipper via SD and stock bootloader is no problem. And I verified that Katapult is flashed with my st-link. But after the installation of Katapult the serial flash command will not work.

I will try 2 things later

• Flashing Katapult direktly with my st-link
• Add a LED to a port pin which is I could use for that purpose. Just to see if Katapult is active.

I presume that this board is a legit STM32F103, and not one of the GD32 clones

It looks to me like a normal STM32 and not a clone. I have a SKR Mini V2 Board which has the same controller (same ARM / STM labeling).

[DrKlipper]

Update Ok, just cleared the whole flash and flashed Katapult with my ST-Link. Attached a LED to Pin PB14 and Katapult worked. LED is blinking und flashing Klipper with this command ~/katapult/scripts/flashtool.py -d /dev/ttyUSB0 -f ~/klipper/out/klipper.bin -b 250000 -v works perfect.

Now I will reinstall the preinstalled bootloader + Marlin to check the deployer way.

[DrKlipper]

Just dig a little deeper and think I found the problem.

First of all I reinstalled the stock firmware (complete flash with stock bootloader and Marlin) with my ST-Link. Then I compiled Katapult with these settings:

    Micro-controller Architecture (STMicroelectronics STM32)  --->
    Processor model (STM32F103)  --->
[ ] Only 10KiB of RAM (for rare stm32f103x6 variant)
[ ] Disable SWD at startup (for GigaDevice stm32f103 clones)
    Build Katapult deployment application (28KiB bootloader)  --->
    Clock Reference (8 MHz crystal)  --->
    Communication interface (Serial (on USART1 PA10/PA9))  --->
    Application start offset (8KiB offset)  --->
(250000) Baud rate for serial port
()  GPIO pins to set on bootloader entry
[*] Support bootloader entry on rapid double click of reset button
[ ] Enable bootloader entry on button (or gpio) state
[*] Enable Status LED
(PB14)  Status LED GPIO Pin

Now I flashed the deployer.bin via SD card. After the flashing via SD is done the LED starts blinking, so Katapult was started. If I reset the board the LED is off - and Katapult is not running. And you have no chance to flash the board via ~/katapult/scripts/flashtool.py

So I connected my ST-Link again and found this: As expected Katapult is at the beginning of the flash ...

I set the Application Offset in Katapult to 8k which equals 0x2000h: As you can see there is still some old garbage left over from Marlin (or the stock bootloader). And I assume the Katapult starts exactly this "code" which can not work.

So I tried to write 0xFF FF FF FF FF FF FF FF to the Application Start:

And now Katapult starts fine after resetting the board.

I wonder if you can change the deployer to delete the first bytes of the Application area (in my case 0x08002000)? Or maybe even better ... Delete all the flash memory after the katapult code.

The stock bootloader used 28k and Katapult uses 8 or 4k. So the old firmware won't run in any circumstances. Keeping the flash filled makes no sense to me.

Oh and I forgot one thing ... I know there is the way of double press the reset button to enter Katapult. But the creality board don´t has any reset button at all. You have to use some breakout wire and pin on some resistors in order to get a proper reset. So not really user friendly I suppose.

Dominik

[Arksine]

We can't erase all flash after Katapult as it would result in the deployer deleting itself. Generally its probably not a good idea to write to the application area while the deployer could be in it. Its possible to add, but I think unnecessary.

As you have observed, the double reset is the primary solution when using the deployer. Boards that don't have a reset button can configure the Enable bootloader entry on button (or gpio) state option. The user just needs to wire a jumper between the configured gpio and Vcc or Ground, depending on configuration.

[DrKlipper]

Ok using an extra wire for the deployer could be a solution.

We can't erase all flash after Katapult as it would result in the deployer deleting itself.

Got the point. But maybe Katapult could erase the rest of the flash after the first run? Maybe the deployer can set some flag in the flash signaling Katapult that it is started the first time. So Katapult can erase the Flash, delete the flag and it´s done. It´s just an idea :-)

It would just prevent people from having extra hardware / extra wiring to get Katapult running.

[DrKlipper]

Unfortunately, I have to ask something again. Catapult and Klipper are installed on my board and Klipper is running. When I now start a Klipper update, it cannot reach the bootloader with any of the following commands:

• make flash FLASH_DEVICE=/dev/ttyUSB0
• make serialflash FLASH_DEVICE=/dev/ttyUSB0
• ~/katapult/scripts/flashtool.py -d /dev/ttyUSB0 -f ~/klipper/out/klipper.bin -b 250000 -v

Does it work at all with the STM32 F103 that Klipper starts the bootloader (in this case Katapult) in order to install an update? Or do I have to explicitly double-tap Reset (or an extra GPIO) to activate Catapult for flashing?

[Arksine]

It is possible to request the serial bootloader. You can't use make to do it, but you could write your own small script. Eventually we'll likely come up with a better way to unify all of this in Klipper.

[DrKlipper]

Ok in this case I think using the SD Method is easier as soon as Klipper is installed.
./scripts/flash-sdcard.sh /dev/ttyUSB0 creality-v4.2.7

This needs only one reboot and no Reset or button pressing.

Would be great if Katapult / Klipper gets a mechanism to update F103 Boards without any user interaction.

Anyway. Thx for your help and information on this topic!