MCU / Printerboard: Creality V4.3.1 with STM32 F103
Describe your issue:
Hi all,
I am very frustrated. I programmed already plenty of MCU, but really struggeling with flashing klipper. I have 2 boards Creality V4.3.1 with STM32F102 RET6 chips. I had klipper flashed on them before, but wanted to upgrade my 1.5 year old installation. The support for this board is not great, I couldn’t find any PCB layout. However, it seems like BOOT 0 and BOOT 1 are not broken out and has not reset button either.
I had trouble finding a working SD card, tried 5 different cards and format fat16 and 32 with different blocksizes.
I gave up on the SD cards and used a jumper cable to bring BOOT 0 high to bring it in bootloader mode and flashed the klipper firmware. I used the old settings (28kbit bootloader offset) as well as USAR1 (USB) and the connection over USART3 PB11/PB10 connection (FTDI Adapter). Not matter what I flash I can not connect with my raspberry pi to the MCU. I always get the same timeout error.
Bringing BOOT0 is cumbersome, so I tried to flash a different bootloader, I tried the STM32duino, the HID and MSC bootloader. Compiled the firmware with different bootloader offsets,… Flashed all with the stm32flash command line tool under linux. I still can not get a DFU, or mass storage device.
I still can flash the MCU with whaterver I want, brining boot 0 high.
I am just at the end what I should try to get it work. I need some real help her.
I don’t even ask for unpaid help, if someone helps me, I am willing to pay someone for that and increase the documentation for future users. That I am serious about this you can see here GitHub - xsnoopy/Ender6: Ender 6 notes
I have pretty good linux and programming skills, but the lack of documentation really sucks. Throwing away 2 good boards just because I am not able to flash them corretly seems also to be not smart.
Try using CanBoot; it can be used for USB, UART, & CAN bus. If the USB option is used, then CanBoot will have a different USB-ID than Klipper, and firmware loading can be done by double-clicking reset (no need for your boot jumper wire) to get CanBoot into firmware loading. I store the CanBoot USB-ID as a comment in my printer.cfg for easy access.
Well, CanBoot was the only bootloader I did not try. I thought this was only for CANBUS. I submitted a pull request already to the klipper documentation to correct that.
Quick question, in CanBoot menuconfig I can set a GPIO Pin to bring the MCU in Bootloader mode, that would be way easier than bringing BOOT 0 high with a jumper wire. Can I double use USART 3 PB11 TX which is broken out on the 10 pin header for that?
I wish there would be somewhere a PCB Layout for the board, not sure where the LED is connected for example.
The reset option is the easiest, double click the reset and it’s in firmware loading mode.
First get the board into DFU mode.
There is dfu-util that can flash CanBoot.
You will use lsusb to get the DFU ID then
sudo dfu-util -a 0 -D ~/CanBoot/out/canboot.bin --dfuse-address 0x08000000:force:mass-erase:leave -d XXXX:XXXX
replace XXXX:XXXX with the DFU ID for the STM32F103, STM are typically 0483:df11
This will get CanBoot in place.
Reset the board, then ls /dev/serial/by-id/
Find the USB-ID that has CanBoot in it, copy it.
To flash Klipper.
Compile Klipper for the board. Make sure to set the same bootloader offset as you did for CanBoot.
Then cd ~/CanBoot
python3 flash_can.py -d /dev/serial/by-id/
Sorry, took me a second. This is how I currently do it. I have the red jumper cable connected to VCC from the SD Card Slot soldering pad. I put that on BOOT 0 and plug in USB. Then I can use stm32flash to flash. I put some text over the picture.
Question, reset needs to twice high or twice low in 500ms to start CanBoot?
I currently do not have the display connected. If it works, I would love to have the display, but if I need to sacrifice the display for the reset, it would be fine too.
I guess my problem is that I never get a DFU device. I just checked my syslog, if I put the board in with BOOT 0 low or high it always shows up as the exactly the same device.
If BOOT 0 was high at boot, I can flash with stm32flash as I did above.
I got it working. The documentary is pretty bad. I submitted some pull requests. I was able to flash CanBoot and the newest version of klipper. Both are working now. Had to use the STM 32 cube Programmer and see what was going on in the memory.
What a nightmare!
@NAPCAL Took me a little second, but I have some general understanding questions before I further update the wiki and documentation of klipper.
I understand it this way: in a STM32F103 you have 255 pages of memory you can flash. The MCU has a very simple bootloader which always points on the first register of the first page. (That way you can never damage the MCU by flashing the wrong code to it). From there a secondary bootloader E.G. from Creality takes over and proved functions like SD flash,… followed by the firmware E.G. Klipper.
During compiling of firmware or bootloader you have to tell what its offset is, in order to have the code starting at the right page and jumping in the code to the correct following page.
If you flash then the code you have to tell the programming tool where to start placing the code.
I have attached a picture which explains what I mean. Could you verify that and if that works?
Would it be possible to have multiple bootloader working behind each other?
Forget to mention, if you compile a bootloader E.G. CanBoot you have to tell CanBoot the size which is uses to determin where the bootloader continues when its finished. E.G. 4Kbit (Page 3) or 8Kbit (Page5.