PlatformIO Community

Octopus Pro v1.0.1 Firmware - framework-arduinoststm32

Hi,

I’m struggling to compile a hello-world for this board and I feel like I’ve tried everything - I’m lost

It’s the BIGTREETECH Octopus Pro with STM32F429ZGT6 MCU, undocumented revision 1.0.1, only source of configurations is from the official GitHub, since PlatformIO nor STM32 platform doesn’t really know this board and MCU.

I’m trying to do a fresh configuration with PlatformIO on vscode, everything updated.

[env:localBoard]
platform = ststm32@~12.1
board = marlin_BigTree_Octopus_Pro_v1_F429
framework = arduino
board_build.core = stm32
board_build.offset = 0x8000
build_flags = 	-D PIO_FRAMEWORK_ARDUINO_ENABLE_CDC
				-D PIO_FRAMEWORK_ARDUINO_NANOLIB_FLOAT_PRINTF
				-D PIO_FRAMEWORK_ARDUINO_USB_HIGHSPEED_FULLMODE
				-DPIO_FRAMEWORK_ARDUINO_OFFICIAL

If I use the marlin_BigTree_Octopus_Pro_v1_F429.json board with the matching MARLIN_BIGTREE_OCTOPUS_PRO_V1_F429 variant from the official repository, it builds correctly, but I suspect the configuration is somewhere incomplete since I don’t have even the basic functionalities of Arduino.h

#include <Arduino.h>

void setup() {
    Serial.begin(9600);
}

error: 'Serial' was not declared in this scope; did you mean 'Serial9'?

I would kind of expect this stuff to be a problem with a configuration of a multiplatform project, like in the case of Marlin, but I only have one board with one variant, so… what’s going on here?

I’ve tried many more combinations of boards with the same-ish MCU and their respective variants from the framework-arduinoststm32 package and ststm32 platform, but they had their own issues with linking errors and stuff, so I would probably start this investigation of ‘where am I completely wrong’ with this config.

I’ve looked at examples in this repo, and some of them use the Arduino functions rather effortlessly, with envs using the same platform and framework.

So, could someone point me in the right direction on creating a clean setup for such board with the Arduino framework?
I feel like I’ve missed something really obvious, but, I can’t find out what it is

Hm interesting, we had a discussion about the Octopus board (Nucleo_f446ze does not support Arduino framework. Looking for advice) some time ago, but that was using a STM32F446ZE.

There’s also the related topic STM32F103RE Bootloader offset which makes a minimal example of a board based on the Marlin variant.

Can you try GitHub - maxgerhardt/pio-octopus-1.0.1-minimal?

This might be important:

Thank you for the references to those similar issues - turns out that I might have the same problem as zouden - it does compile, both with Serial and SerialUSB, but it doesn’t really open that port on the USB-C.

I’ve forgotten to mention the board_build.offset = 0x8000, which I was using and it does flash correctly via SD card, I can see it being copied to the right place in the STM32CubeProgrammer.

I’ve tried using the linker script STM32F446ZETx_FLASH.ld but I feel like it won’t be as easy as that - yes, I have no clue what it does xD kek

That is the result when using →

?

Yes, using this repo you provided - intact this time xD

I’ve messed with it yesterday, so I’ve just double checked now.
Even cleared the whole .platformio folder and reflashed bootloader

Do you have direct flash access to the board via an ST-Link / an SWD probe? If you have the bootloader backed up, I would try uploading a firmware without offset and see if that runs and live-debug it if needed (supported with any SWD probe), maybe it’s stuck somewhere. But the firmware build setup should actually be what Marlin does, copy-pasted…

I unfortunately don’t have that programmer, might be a good idea to get one…

I’ve already tried that yesterday, loaded the firmware.bin directly at 0x8000000 and nothing.
As the bootloader, I’m using the Octopus-F429-bootloader-32KB(Flash 1MB).hex from here. Interesting thing is that STM32CubeProgrammer says that the MCU has 2MB of flash…

Can the bootloader itself be bad? I have unfortunately erased the one the board came with…

EDIT: yeah even if it was bad, uploading it alone to the flash rules out the bootloader being at fault…

But at https://www.mouser.de/ProductDetail/STMicroelectronics/STM32F429ZGT6?qs=DqCdCwOw4%2F61O51evUvYMQ%3D%3D I see a document for “STM32F4x 2Mbyte products improvement (PDF)” with their new die revision, so that can be well-possible. It’s free real estate.

I can only recommend getting a cheap ST-Link clone for like 5€ on ebay, I couldn’t imagine developing without it.

But actually, after looking at the schematics (sadly ony Octopus V1.0?) here, the SWD pins are not available ad header pins. SWDIO goes to an LED and SWCLK goes to DRIVER7_DIR of a motor driver. It would need some soldering to hook onto the needed resistor before the LED and driver module IC. :confused:

Yeah that’s gonna be fun…

I’m probably going to check the ST datasheet pinout with the Octopus V1.0 to be sure.
Not even is it not Octopus Pro, but mine is V1.0.1 so…
The board layout already is different, so there is a chance the pinout is also different

Well the BOOT0 pin is at the J75 header though, so if you jumper these 2 pins and re-power the board, yyou should be able set upload_protocol = dfu and upload the firmware as normal (with 0 offset).

If Arduino does not work, try a more minimal HAL project: platform-ststm32/examples/stm32cube-hal-blink at develop · platformio/platform-ststm32 · GitHub

I’ve tried to stay away from HAL, but I’m gonna give that a try

It blinks!!!

So the stm32cube-hal-blink does work if being loaded at 0x8000000.
If the bootloader loads it from SD card, it can’t start it, but it’s there.

I’ve found this in the datasheet:

The STM32F427xx and STM32F429xx devices are part of the STM32F4 family. They are
fully pin-to-pin, software and feature compatible with the STM32F2xx devices [...]

I’m gonna go back to Arduino a try some boards with the F2 MCU, perhaps there is something wrong with the Marlin F429 variant definitions

EDIT: I actually never tried blink on the previous configs, so I’ll start with that

Arduino works!!
Sort of…

The problem was the offset, if I upload it via the STM32CubeProgrammer, there is nothing to offset anymore.

So it compiles and runs on ststm32@~12.1, but the Serial still doesn’t work.
It does not compile under ststm32, the latest version, it throws the linking errors I was talking about in the first post:

Linking .pio\build\localBoardArdMini\firmware.elf
c:/users/danie/.platformio/packages/toolchain-gccarmnoneeabi/bin/../lib/gcc/arm-none-eabi/9.2.1/../../../../arm-none-eabi/bin/ld.exe: .pio/build/localBoardArdMini/libFrameworkArduino.a(wiring_digital.c.o): in function `pinMode':
wiring_digital.c:(.text.pinMode+0xc0): undefined reference to `analogInputPin'
c:/users/danie/.platformio/packages/toolchain-gccarmnoneeabi/bin/../lib/gcc/arm-none-eabi/9.2.1/../../../../arm-none-eabi/bin/ld.exe: .pio/build/localBoardArdMini/libFrameworkArduino.a(wiring_digital.c.o): in function `digitalWrite':
wiring_digital.c:(.text.digitalWrite+0x70): undefined reference to `analogInputPin'
c:/users/danie/.platformio/packages/toolchain-gccarmnoneeabi/bin/../lib/gcc/arm-none-eabi/9.2.1/../../../../arm-none-eabi/bin/ld.exe: .pio/build/localBoardArdMini/libFrameworkArduino.a(HardwareSerial.cpp.o): in function `HardwareSerial::setRx(unsigned long)':     
HardwareSerial.cpp:(.text._ZN14HardwareSerial5setRxEm+0x44): undefined reference to `analogInputPin'
c:/users/danie/.platformio/packages/toolchain-gccarmnoneeabi/bin/../lib/gcc/arm-none-eabi/9.2.1/../../../../arm-none-eabi/bin/ld.exe: .pio/build/localBoardArdMini/libFrameworkArduino.a(HardwareSerial.cpp.o): in function `HardwareSerial::setTx(unsigned long)':     
HardwareSerial.cpp:(.text._ZN14HardwareSerial5setTxEm+0x44): undefined reference to `analogInputPin'
collect2.exe: error: ld returned 1 exit status
*** [.pio\build\localBoardArdMini\firmware.elf] Error 1

Meaning if you take the firmware.bin and place it on the SD card, the bootloader on the board doesn’t write it to the correct place, but if you use STM32CubeProgrammer to upload it to the wanted address, it works?

I’ve also seen that, the variant folder that comes from Marlin is not suitable for the new arduino core, some names seem to have changed.

If I take the firmware.bin built with the offset and place it on the SD card, it gets copied at the 0x8000 address, the bootloader ends at 0x7110, the filename does change to .CUR, but it doesn’t run.

I could try to build it without the offset and upload it via the SD card, maybe it’s not necessary to offset it at all. But the upload method doesn’t really matter, the broken Serial kind of does…

So ArduinoIDE can make the Serial via USB work.

The support of this MCU is listed in the Arduino_Core_STM32 repo, so I just quickly checked if it’s true and boom, Serial is working.

So there exists a functional configuration for Arduino on STM32F429ZGT6, I’m going to extract the juicy stuff from there and make a repo or something, since I don’t like the IDE.