Closed DumpsterDave closed 2 years ago
Unless I'm misinterpreting your comment it sounds like you are trying to flash klipper onto a board directly rather than using CANboot?
I haven't specifically documented a no bootloader flash as honestly CANboot has been relaible and much more convenient for me and others who have followed this guide (and you are the first to report this specifically being an issue, in several months since I wrote the steps for this board and the v.1.1 which shares the same MCU.)
The steps are written to be used together with the assumption that CANboot is in use. So as the CANboot bootloader uses an 8KiB application offset. Flashing klipper without a bootloader offset would effectively overwrite CANboot or put the application start in the wrong place?
I think you're right. I think what's happening is that STM32 always starts writing at address 0x08000000 which is the start of the flash space. When writing using flash_can to write klipper, it seems to start at the flash address + application offset and does not erase the blocks before that (CanBoot). When you compile klipper without the bootloader offset and flash with STM32, the entry point sits at 0x08000000 and loads since that's the start of the flash. When you compile klipper with the bootloader offset and flash with STM32, it still places the file at 0x08000000, but the entry point is not there so it doesn't load.
Attempting to flash a BTT ebb36 v1.2 with G0B1 does not work if you select a Bootloader offset of 8 KiB. The device will flash but cause the network to go into an ERROR-PASSIVE state as soon as communication is attempted on the canbus. Compiling the firmware with No bootloader selected works fine and the device can successfully communicate with klipper. Flashing (with full memory erase) was done with STM32 programmer and was attempted at multiple different baud rates (250k, 500k, 750k, 800k, 1M).