Board does not run with Marlin 2.0 PlatformIO compile about rumba32 HOT 9 CLOSED

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.

from rumba32.

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!

from rumba32.

@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

from rumba32.

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.

from rumba32.

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.

from rumba32.

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.

from rumba32.

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.

from rumba32.

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).

from rumba32.

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.

from rumba32.