Board does not run with Marlin 2.0 PlatformIO compile

[capibara1]

I am trying to do the following without success:

1. Compile Marlin-2.0.x
2. Upload it to the board
3. Have the board do its usual reset and start running Marling.

Marlin setup

Marlin versions affected:
Marlin-2.0.x (currently 2.0.5.3)

Marlin configurations:
These are the only Configuration.h changes that I am making to keep the process simpler:

#define SERIAL_PORT = -1
#define MOTHERBOARD BOARD_RUMBA32_AUS3D
#define DEFAULT_NOMINAL_FILAMENT_DIA 1.75
#define X_DRIVER_TYPE A4988
#define Y_DRIVER_TYPE A4988
#define Z_DRIVER_TYPE A4988
#define E0_DRIVER_TYPE A4988

Configuration_adv.h not changed at all

Compilation Issues

1. First compile issue: Arduino IDE compile is impossible. It fails with any version of STM32duino (1.9.0). Abandoned this approach for PlatformIO. I hope instructions for future users are updated to encourage include PlatformIO. Issue Instructions for RUMBA32 Marlin compile are obsolete #22.

2. Marlin platformio.ini file for RUMBA32 is incorrect. It needs to be changed (Issue Connection fails with Octoprint #21, Issue platformIO setup for Marlin #11 )
   This is what the Marlin platformio.ini has for BOARD_RUMBA_32_AUS3D (with annotated changes/questions):

[env:rumba32_f446ve]
platform = ststm32
board = rumba32_f446ve
build_flags = ${common.build_flags}
-DSTM32F4xx
-DARDUINO_RUMBA32_F446VE
-DARDUINO_ARCH_STM32
"-DBOARD_NAME="RUMBA32_F446VE""
-DSTM32F446xx
-DUSBCON
-DUSBD_VID=0x0483 --> CORRECT? (See here RUMBA MKS board uses 0x8000. It compiles with either value, but what is the correct one and does it matter?)
"-DUSB_MANUFACTURER="Unknown""
"-DUSB_PRODUCT="RUMBA32_F446VE""
-DHAL_PCD_MODULE_ENABLED
-DUSBD_USE_CDC
-DDISABLE_GENERIC_SERIALUSB
-DHAL_UART_MODULE_ENABLED
-Os
lib_ignore = Adafruit NeoPixel
**src_filter = ${common.default_src_filter} +<src/HAL/STM32> --> MISSING ENTRIES absolutely needed to compile: +<src/HAL/STM32_F4_F7> -<src/HAL/STM32_F4_F7/STM32F7> **
** monitor_speed = 500000 --> Should this be 250000 ? **
upload_protocol = dfu
lib_deps = ${common.lib_deps} --> MISSING (See here and issue #11 )

Modifying the platformio.ini file compiles successfully, however:

Uploading and Running (or not)

With the platformio.ini setting for upload_protocol=dfu, the compiler attaches a dfu suffix to the firmware.bin file:
Advanced Memory Usage is available via "PlatformIO Home > Project Inspect"
RAM: [= ] 5.4% (used 7060 bytes from 131072 bytes)
Flash: [== ] 17.4% (used 91124 bytes from 524288 bytes)
Adding dfu suffix to firmware.bin
dfu-suffix (dfu-util) 0.9

Copyright 2011-2012 Stefan Schmidt, 2013-2014 Tormod Volden
This program is Free Software and has ABSOLUTELY NO WARRANTY
Please report bugs to http://sourceforge.net/p/dfu-util/tickets/

Suffix successfully added to file

And it can be uploaded to the RUMBA32 (in Bootloader mode). It uploads successfully:

Configuring upload protocol...
AVAILABLE: blackmagic, dfu, jlink, serial, stlink
CURRENT: upload_protocol = dfu
Uploading .pio/build/rumba32_f446ve/firmware.bin
dfu-util 0.9

Copyright 2005-2009 Weston Schmidt, Harald Welte and OpenMoko Inc.
Copyright 2010-2020 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/

Match vendor ID from file: 0483
Match product ID from file: df11
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
DfuSe interface name: "Internal Flash "
Downloading to address = 0x08000000, size = 91644
Download [=========================] 100% 91644 bytes
Download done.
File downloaded successfully
Transitioning to dfuMANIFEST state

After successful compile I expect the board to reset and start running the program But then the board does not restart. The orange LED1 does not flash at all and there is no way to get the board to start running Marlin.
Doing an lsu's (MacOS), I can see the board is connected in "FS mode". I don't know what that is but there is no communication with the board via host software (Pronterface).

Bus 020 Device 025: ID 0483:5740 STMicroelectronics RUMBA32_F446VE CDC in FS Mode Serial: 376933553337

I don't know what else to try at this point. I am very frustrated with this. For now, my board is bricked. Any help is appreciated.

[chrissbarr]

Hi @capibara1, sorry to hear this isn't working. Please check the PlatformIO instructions I've just posted in the other issue (#22 (comment)) and see if they work for you. I did not have to modify the platformio.ini file for this to work.

Let me know if you can get it running with those instructions.

[capibara1]

HI Chris,
I appreciate the instructions. Hopefully the will become the default instructions in the "Getting RUMBA32 Up and Running page" instead of buried in a GitHub issue thread.

I was just able to compile the master branch of Marlin 2.0.x (tag 2.0.5.3) by using and modifying the platform.ini file from the bug fix branch:

1. git clone https://github.com/MarlinFirmware/Marlin.git
2. git clone -branch bugfix-2.0.x https://github.com/MarlinFirmware/Marlin.git
3. cp Marlin-bugfix-2.0.x/platformio.ini Marlin/.
4. Edit Marlin/platformio.ini:

Replace:

src_filter = ${common.default_src_filter} +<src/HAL/STM32>

with

src_filter = ${common.default_src_filter} +<src/HAL/STM32> +<src/HAL/STM32_F4_F7> -<src/HAL/STM32_F4_F7/STM32F7>

That compiled and uploaded completely (with a few warnings, see log below). Now I can finally connect to the board!

Next, I will attempt the compile with the full Marlin configuration files. I will update what I find.

Thank you!

[capibara1]

@chrissbarr
Yes, I can compile the master branch 2.0.x with full configuration and that platformio.ini modification explained above but the fans don't work at all, the LCD screen is totally garbled and there is an error message that was reported in issue #21 : Err: EEPROM Version.

The bugfix-2.0.x version compiles and uploads without modifications to the platformio.ini and the printer shows the correct message "AUS3D RUMBA32 Ready" but the LCD screen is still garbled, and fans still don't work at all (FAN onboard LED lights up but fan doesn't spin). So the printer is not useable at all.

The LCD issue may have something to do with the LiquidCrystal 1.5.0 library. See compile warnings in the attached file. The fans, I will have to look back at issue #21 but I don't think there was a resolution to the issue (fans did not end up spinning)

What do you suggest as a next step?

LCD_compile_warnings.txt

[chrissbarr]

Hi @capibara1,

I believe the resolution to the fans issue in #21 was successful - @McPrince96 added an edit to his message stating that the fans were working (see #21 (comment)). The fix here was to use the soft PWM feature in Marlin (#define FAN_SOFT_PWM). I've also tested this on my board here and it is working for me. It would be better to have the hardware PWM working, but until the underlying issue is found and corrected the soft PWM should be a very usable solution. You can experiment with the options for frequency and dithering if you'd like.

I am not clear on why the platformio.ini modification was needed. Were you getting some error without this?

I think including the <src/HAL/STM32_F4_F7> will cause you trouble, as the HAL described in those folders uses an entirely different Arduino Core - it targets the older STM32Generic Arduino Core, whereas RUMBA32 support in Marlin uses the official STM32Duino Core, which is targeted in the <src/HAL/STM32> folder. I do not know what effect including both would have - hopefully, the #ifdef guards in the HAL headers will make it so that only one of the HALs is used, preferably the one that supports RUMBA32. I can't guarantee that this is what is happening though, so I would advise against including these extra folders.

I've seen the LCD issue before - I believe that is a result of timing problem coming from the faster microcontroller, where the original code was built around the slower 8-bit devices. Testing with a display I have on hand, I see the same thing. Adding these lines to the end of the Configuration.h file solves it for me:

#define ST7920_DELAY_1 DELAY_NS(600)
#define ST7920_DELAY_2 DELAY_NS(750)
#define ST7920_DELAY_3 DELAY_NS(750)

I have not experimented with the delays. It is possible that they could be made shorter, but I don't know if there's any advantage to doing so.

[chrissbarr]

On the EEPROM error - that should go away once you have saved values to EEPROM (M500) once. You may need to do an M502 (settings reset) first - I'm unsure. If that doesn't do it, let me know and I'll check further.

[chrissbarr]

I've just been having a look at the Marlin troubleshooting docs. I see they touch on this EEPROM error here, and that seems to confirm that an M502 followed by an M500 should initialise the EEPROM as required.

The LCD problem is also discussed and the same solution of adding the above delays is suggested, though with different values. I've had these delays kicking around for a while and am not sure where I first came across them - so I'm not sure if there's any significance in the different values. The ones above have worked for me - if they don't do the trick for you, maybe try the delays given in the Marlin docs instead.

[capibara1]

Thanks Chris,

Finally everything (compile/upload/run) is working now for the AUS3D RUMBA32, at least for the bugfix-2.0.x Marlin release.
Combination that works for other's benefit:

• Marlin-bugfix-2.0.x (This specific commit)
• Compile using VSCode with PlatformIO - Arduino IDE method does not work.
• platformio.ini - Default that comes with Marlin, no changes
• Configuration.h
  • #define MOTHERBOARD BOARD_RUMBA32_AUS3D
  • #define SERIAL_PORT -1
  • Fan PWM workaround (or fans won't start): #define FAN_SOFT_PWM
  • LCD (this was my specific screen issue for RepRap Discount Full Graphic Display, delay values may be different for others):

 #define ST7920_DELAY_1 DELAY_NS(200)
 #define ST7920_DELAY_2 DELAY_NS(350)
 #define ST7920_DELAY_3 DELAY_NS(200)

• EEPROM error may or may not show up (is intermittent for me): Just execute M502, M500 after connecting to host software. Should always do this when new firmware is uploaded anyways.

[chrissbarr]

That's great news @capibara1, glad to hear it!

Thanks for noting the info/configuration that has worked for you, that's a big help and will be useful to others I am sure.

I will amend the documentation shortly to use the PlatformIO method, rather than the Arduino IDE method.

I'll close this issue now, but if you run into more trouble with this feel free to leave a comment and we will reopen it (or open a new issue - whatever you prefer).

[capibara1]

I appreciate the help Chris!

Note: the "EEPROM Version Error. Initialize EEPROM?" shows up every time after reset, even if M502/M500 are executed. When M501 (Restore settings from EEPROM) is executed, you still get the "EEPROM version mismatch (EEPROM= Marlin=V79)"

How can we eventually have the RUMBA32 compile out of the master Marlin-2.0.x branch? It seems that it perpetually and only works with the bug fix branch and that is not great for stability.

Thanks again.