Recently, I’ve been struggling with STM32 firmware and how it is stored in Flash for some of the things that I’ve been doing.
Can I throw something out there as a question?
How do you know you’re actually updating the Flash in the EBB42’s MCU and not storing it in SRAM and executing from there?
If you are writing the Klipper firmware to SRAM (at the appropriate address there), the code will execute correctly until you power down the MCU and restart it - only to discover that you have to reflash the MCU again. I think this hypothesis matches what you are experiencing.
What is the process that you’re using for building your EBB42 firmware and flashing the board’s MCU?
This hypothesis doesn’t quite resonate with my experience. I think my experience is less
And more:
”Change printer.cfg, save and restart klipper service - only to discover I have to reflash.”
The question is, whether the “save and restart” process after changing printer.cfg is performing a “firmware reset” on the mcu as well as the klipper services on the Pi, but somehow shutting down the pi and restarting (including any klipper-related services) does not have the same effect (the
I am running ./kiauh/kiauh.sh over SSH. I usually select kiauh V6 Beta (but have tried V5 and seen no difference). I then go into
4) Advanced options,
3) build, flash.
architecture STM32, processor STM32G0B1, - Bootloader offset = 8KiB bootloader, - Clock Reference = 8 MHz crystal, Communication interface = CAN bus (on PB0/PB1), (1000000) CAN bus speed (or 250k at the moment)
select regular flashing method
Put the toolboard into dfu mode by holding boot button while pressing and releasing reset button
make flash (not stm32flash)
USB DFU mode
for the only DFU VID/PID present (samd21 and rp2040 are not shown, as expected) y confirm the flashing action
But you know what? I think I had some errors in the flash read-back at the end of the flashing. This sounds highly consistent with your theory. I put this down to V6 Beta kiauh and didn’t have any improvement/different behaviour with V5 (but don’t recall seeing the flash readback error there). I did check whether the stm32flash method was needed but the source I referred to did not use it and said to use the normal flash method for stm32 over dfu.
This sounds like an issue I had with a Nitehawk USB board before. It would work fine across multiple Klipper restarts, but when I change the config file I would have to reboot the Pi to connect to it. The solution for that ended up being a resistor that needed to be removed on the USB adapter board, so I’m wondering if it might be a hardware issue in this case as well (I know USB and CAN are very different, so this is a “maybe”).
I’ll take this as a good starting point, thank you. Speaking of resistors, I have measured my bus resistance with the boards powered down - around 70 Ohms, which seems a bit weird, as if they are using standard values to approximate 120 Ohms at each end (to be clear, I only have the U2C and a single EBB42 on the bus atm, both with their 120 Ohm jumpers installed)
Having read a little more about kiauh, it seems that flashing stm32s in dfu mode frequently shows a “flash failed” message at the end, due to the chip ID varying between dfu mode and normal application mode. So that’s less suspicious than I originally thought.
When you put a board into DFU mode, you’re loading the firmware into the boot portion of the Flash - NOT THE BOOTLOADER OFFSET.
When you specify “Bootloader offset = 8KiB bootloader” you’re specifying that the firmware will start executing at the boot offset + 8K, not the boot offset.
Could you try this again with “Bootloader offset = No bootloader” as per:
Personally, I would recommend that you install Katapult into the EBB42, as set out in the Esoterical instructions as this will allow you to update firmware updates without disconnecting CAN and connecting a USB cable.
What does this mean? Are you running at 1Mbps or 250kbps?
Could you disconnect the CAN cable measure the resistance at both the U2C and the EBB42 and report back? Also, could you explain how you measured things to get 70Ω?
Well I just got a chance to try this and it certainly seems to show promise. I flashed with 0kb bootloader offset and then commented out a motor in printer.cfg while leaving its mcu intact. Then “save and restart” button in mainsail web dashboard. The EBB42 came straight back up. More testing to be done but thank you very much @mykepredko !
I dropped everything down to 250kbps in case my wiring/speed was the issue
I put a multimeter across the CANH and CANL pins on the U2C’s molex connector. I will remeasure without the CAN cable next time I power down.
I was not originally open to this idea, as you can see how flaky my canbus communication has been - it would have been no good for flashing/booting over! I will reconsider once I have confidence in the bus again, which shouldn’t be too long if this fix persists.
