`make flash` & Octopus Pro board

General Discussion
1

Basic Information:

Printer Model: n/a
MCU / Printerboard: Octopus Pro / F429 chip
klippy.log: not running

Describe your issue:

I want to flash my Octopus Pro board without having to resort to the SD card. I’m doing firmware development so the SD card is a real roadblock to getting things done. (just imagine turning your Voron 2.4 upside down 3 times an hour just to test something…)

The klipper instructions say to use this command to flash the board:

make flash FLASH_DEVICE=/dev/serial/by-id/<ypur-device-id-goes-here>

This is very convenient for development. I’ve had this work on other boards, including other versions of the Octopus (non-Pro).

But on this Octopus Pro board it has never worked. I can manually put that board into DFU mode with the Boot0 jumper but I cant even flash it that way, only via the SD card. dfu-util can talk to it but it cant ‘parse the memory layout’:

pi@voron24:~/klipper $ lsusb
Bus 001 Device 007: ID 0483:df11 STMicroelectronics STM Device in DFU Mode

pi@voron24:~/klipper $ sudo dfu-util -d 0483:df11 -R -a 0 -s 0x8008000:leave -D out/klipper.bin
dfu-util 0.9

Copyright 2005-2009 Weston Schmidt, Harald Welte and OpenMoko Inc.
Copyright 2010-2016 Tormod Volden and Stefan Schmidt
This program is Free Software and has ABSOLUTELY NO WARRANTY
Please report bugs to http://sourceforge.net/p/dfu-util/tickets/

dfu-util: Invalid DFU suffix signature
dfu-util: A valid DFU suffix will be required in a future dfu-util release!!!
Opening DFU capable USB device...
ID 0483:df11
Run-time device DFU version 011a
Claiming USB DFU Interface...
Setting Alternate Setting #0 ...
Determining device status: state = dfuERROR, status = 10
dfuERROR, clearing status
Determining device status: state = dfuIDLE, status = 0
dfuIDLE, continuing
DFU mode device DFU version 011a
Device returned transfer size 2048
dfu-util: Could not read name, sscanf returned 0
dfu-util: Failed to parse memory layout

The device always seems to be in dfuERROR state, even from a cold start. Is that normal?

Could the address (0x8008000) is different on this board?

I’ve tried flashing the bootloader with the STM tools as well but this changed nothing.

(I’m going to solve this by taking the board out of the printer and placing it near the :wastebasket:… luckily I have a :octopus: I can steal from another project)

2

Here’s the command I use:

sudo dfu-util -a 0 -D ~/klipper/out/klipper.bin --dfuse-address 0x08000000:force:mass-erase:leave -d 0483:df11

The only differences I see is that I don’t use the “R” option (USB reset after data transfer) and I do a “mass-erase” first.

1 Like
3

The starting address is different, you are using force, and that’s not the same address:

0x8008000:leave
0x8000000:force:mass-erase:leave

worth a shot, at this point I don’t care if I brick it.

4

No luck with those options and either address.

5

Sorry, I should have picked that up. With DFU I don’t care if I trash the bootloader in Flash.

What is your host?

I just did a quick search and found:

AND, which is probably more relevant:

In the second one, note the comment:

  • Support firmware update via DFU mode (Note: If you have 1.0 board, remove heater/bed when entering DFU mode)

Maybe that’s the problem you’re seeing.

1 Like
6

Rummaging around for similar problems it looks like dfu-util reads the memory map out of the USB descriptor. You can get that by running:

lsusb -d 0483:df11 -v

Its long but of particular interest is this section:

   Interface Descriptor:
      bLength                 9
      bDescriptorType         4
      bInterfaceNumber        0
      bAlternateSetting       0
      bNumEndpoints           0
      bInterfaceClass       254 Application Specific Interface
      bInterfaceSubClass      1 Device Firmware Update
      bInterfaceProtocol      2
      iInterface              4 @Internal Flash  /0x08000000/04*016Kg,01*064Kg,07*128Kg챐ƨ⹔뺿䭼뛮컸

This looks sus :
@Internal Flash /0x08000000/04*016Kg,01*064Kg,07*128Kg챐ƨ⹔뺿䭼뛮컸

I have the boot0 jumper on the board so its not even that it cant be kicked into DFU mode over serial. It’s in DFU mode.

7

On the regular Octopus board that block doesn’t have the weird unicode characters:

@Internal Flash /0x08000000/04*016Kg,01*064Kg,03*128Kg

Google Translate says that 챐ƨ⹔뺿䭼뛮컸 is Korean and translates to “It was so big.”

frustrated-man

3 Likes
8

I filed an issue: Errant in USB descriptor breaks dfu-util · Issue #42 · bigtreetech/BIGTREETECH-OCTOPUS-Pro · GitHub

The board has been removed from the printer.

9

Sorry - hopefully it will be addressed quickly.

1 Like
10

If you have a STLink at hand you could just do it the hard way. Or if you do not have one try your luck with the STM32CubeProgrammer in USB mode

Edit:
You could also try reflashing the bootloader either with the one supplied by BTT or straight away with Katapult

1 Like
11

Alternative bootloader, that’s probably a solution. I tried flashing their bootloader but that didn’t change the behavior.

12

Could it be a defective chip? I know the likelihood of that is very low but maybe there’s a problem with the chip’s Flash.

13

FWIW, when I can, I install Katapult on my dev boards. It’s very convenient to be able to use a single bootloader across many different boards.

Cheers,
-Kevin

2 Likes
14

I installed Katapult on the V1 Octopus board I installed in the printer because getting it’s bootloader to enter DFU mode was… random. make flash now seems to work reliably with Katapult.

I’ll try and get time to do the same to the Octopus Pro and report back. But right now its a paper weight.

1 Like
15

This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.