Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

[BUG] Rumba32 (STM32F446) Reboot Loop #16650

Closed
ro-ct opened this issue Jan 22, 2020 · 17 comments
Closed

[BUG] Rumba32 (STM32F446) Reboot Loop #16650

ro-ct opened this issue Jan 22, 2020 · 17 comments

Comments

@ro-ct
Copy link

ro-ct commented Jan 22, 2020 •
edited
Loading

Hey Guys,

I got two new Rumba32-Boards and I want to get it up and running with Marlin, but after flashing the firmware the board seems to hang in a reboot-loop.

Setup

My Configurations

  • Marlin bugfix-2.0.x (as suggested from the Rumba32-Homepage), todays version
  • configuration.h changes:
    • #define SERIAL_PORT -1
    • #define MOTHERBOARD BOARD_RUMBA32
    • #define TEMP_SENSOR_0 998

Behaviour

  • device manager of windows 10 refreshes every 3..5 seconds, when board is attached over USB
  • in Simplify3D, the board is in the same interval available/unavailable. When connecting with Simplify3D, the following happens:
Attempting connection at \\.\COM8… 
Testing plaintext communication protocol…
READ: ok
Connected to machine!
SENT: T0
READ: ok
SENT: M105
READ: ok T:0.00 /0.00 @:0
WARNING: Device unplugged while connected to port
Disconnected.
  • on the one hand the automatic disconnection is one problem but also the temperature should report the DUMMY_THERMISTOR_998_VALUE (default 25) but not 0
  • response in Arduino serial monitor:
13:28:58.467 -> start
13:28:58.467 -> echo: Watchdog Reset
13:28:58.467 -> Marlin bugfix-2.0.x
13:28:58.467 -> 
13:28:58.467 -> echo: Last Updated: 2020-01-21 | Author: (none, default config)
13:28:58.467 -> echo:Compiled: Jan 22 2020
13:28:58.467 -> echo: Free Memory: 123891  PlannerBufferBytes: 1280
13:28:58.467 -> echo:Hardcoded Default Settings Loaded
13:28:58.467 -> echo:  G21    ; Units in mm (mm)
13:28:58.467 -> 
13:28:58.467 -> echo:Filament settings: Disabled
13:28:58.467 -> echo:  M200 D3.00
13:28:58.467 -> echo:  M200 D0
13:28:58.467 -> echo:Steps per unit:
13:28:58.467 -> echo: M92 X80.00 Y80.00 Z4000.00 E500.00
13:28:58.467 -> echo:Maximum feedrates (units/s):
13:28:58.467 -> echo:  M203 X300.00 Y300.00 Z5.00 E25.00
13:28:58.467 -> echo:Maximum Acceleration (units/s2):
13:28:58.467 -> echo:  M201 X3000.00 Y3000.00 Z100.00 E10000.00
13:28:58.467 -> echo:Acceleration (units/s2): P<print_accel> R<retract_accel> T<travel_accel>
13:28:58.467 -> echo:  M204 P3000.00 R3000.00 T3000.00
13:28:58.467 -> echo:Advanced: B<min_segment_time_us> S<min_feedrate> T<min_travel_feedrate> J<junc_dev>
13:28:58.467 -> echo:  M205 B20000.00 S0.00 T0.00 J0.01
13:28:58.467 -> echo:Home offset:
13:28:58.467 -> echo:  M206 X0.00 Y0.00 Z0.00
13:28:58.467 -> echo:PID settings:
13:28:58.467 -> echo:  M301 P22.20 I1.08 D114.00
  • I measured the "kill"-pin of the Rumba32-board (PC5-pin of the stm32-controller): the voltage drops in the same interval from 3.3 V to Gnd.

Flashing Problems

  1. Filename too long

At the beginning I could not even flash Marlin because the file name or extension were too long. I tried a lot like choosing short paths, editing the build.path in the Arduino-preferences, etc. but nothing helped. It seems that the lcd-sources can lead to quite long paths so I removed the folder extension-ui in \src\lcd. After that, flashing was not a problem any more. I just mention this here in case, this might be important again.

  1. Multiple libraries
    The following is an excerpt of Arduino's flash log. Just in case if this is of any relevance.
Multiple libraries were found for "SrcWrapper.h"
 Used: []AppData\Local\Arduino15\packages\STM32\hardware\stm32\1.8.0\libraries\SrcWrapper
Multiple libraries were found for "SPI.h"
 Used: []AppData\Local\Arduino15\packages\STM32\hardware\stm32\1.8.0\libraries\SPI
Multiple libraries were found for "IWatchdog.h"
 Used: []AppData\Local\Arduino15\packages\STM32\hardware\stm32\1.8.0\libraries\IWatchdog
Using library SrcWrapper at version 1.0.1 in folder: []AppData\Local\Arduino15\packages\STM32\hardware\stm32\1.8.0\libraries\SrcWrapper 
Using library SPI at version 1.0 in folder: []AppData\Local\Arduino15\packages\STM32\hardware\stm32\1.8.0\libraries\SPI 
Using library IWatchdog at version 1.0.0 in folder: []AppData\Local\Arduino15\packages\STM32\hardware\stm32\1.8.0\libraries\IWatchdog 
"[]AppData\\Local\\Arduino15\\packages\\STM32\\tools\\xpack-arm-none-eabi-gcc\\9.2.1-1.1/bin/arm-none-eabi-size" -A "C:\\Tmp/Marlin.ino.elf"
Sketch uses 83288 bytes (15%) of program storage space. Maximum is 524288 bytes.
Global variables use 6608 bytes (5%) of dynamic memory, leaving 124464 bytes for local variables. Maximum is 131072 bytes.
[]AppData\Local\Arduino15\packages\STM32\tools\STM32Tools\1.3.2/tools/win/stm32CubeProg.bat 2 C:\Tmp/Marlin.ino.bin -g 
      -------------------------------------------------------------------
                       STM32CubeProgrammer v2.2.0                  
      -------------------------------------------------------------------



USB speed   : Full Speed (12MBit/s)
Manuf. ID   : STMicroelectronics
Product ID  : STM32  BOOTLOADER
SN          : STM32FxSTM32
FW version  : 0x011a
Device ID   : 0x0421
Device name : STM32F446xx
Device type : MCU
Device CPU  : Cortex-M4



Memory Programming ...
Opening and parsing file: Marlin.ino.bin
  File          : Marlin.ino.bin
  Size          : 83792 Bytes
  Address       : 0x08000000 


Erasing memory corresponding to segment 0:
Erasing internal memory sectors [0 4]
erasing sector 0000 @: 0x08000000 done
erasing sector 0001 @: 0x08004000 done
erasing sector 0002 @: 0x08008000 done
erasing sector 0003 @: 0x0800c000 done
erasing sector 0004 @: 0x08010000 done
Download in Progress:

File download complete

What I have tried so far

  • different computers
  • different hosts
  • different usb-cables
  • enabling#define WATCHDOG_RESET_MANUAL
  • both Rumba32-boards
    Nothing changed, the boards still reboot

I really don't know what else I can try so I would appreciate any help or hint to overcome this issue.

Best regards in advance,
ro-ct

config.zip
@ro-ct ro-ct changed the title [BUG] (short description) [BUG] Rumba32 (STM32F446) Reboot Loop Jan 22, 2020
@xC0000005
Copy link
Contributor

If this builds using HAL_STM32, those timers aren't firing correctly, which means if the watchdog is enabled, it's probably rebooting when the temp ISR doesn't work. You can test by disabling the watchdog in config and seeing if it stops rebooting. (I don't have a fix, and am under deadline, but I do know the ISR isn't firing).

@sjasonsmith
Copy link
Contributor

(I don't have a fix, and am under deadline, but I do know the ISR isn't firing).

Is the timer issue you mention specific to the Rumba32, or other boards as well?

@xC0000005
Copy link
Contributor

xC0000005 commented Jan 23, 2020 via email

@sjasonsmith
Copy link
Contributor

No, I have not, but I haven't been actively working with any STM32 boards for a while. Aren't the Chitu and Malyan boards supposed to be using the Maple-based STM32F1 HAL?

@xC0000005
Copy link
Contributor

xC0000005 commented Jan 23, 2020 via email

@ro-ct
Copy link
Author

ro-ct commented Jan 23, 2020

If this builds using HAL_STM32, those timers aren't firing correctly, which means if the watchdog is enabled, it's probably rebooting when the temp ISR doesn't work. You can test by disabling the watchdog in config and seeing if it stops rebooting. (I don't have a fix, and am under deadline, but I do know the ISR isn't firing).

Disabling the watchdog completely in configuration_adv works, the firmware now runs smoothly. I hope this get's fixed soon because I would feel better with the watchdog running like it should.
Thanks @xC0000005

@xC0000005
Copy link
Contributor

Disabling the watchdog is NOT a fix - it's a way to identify that yes, the watchdog is triggering because the temp ISR isn't running. Please don't run anything real without the watchdog.

@boelle
Copy link
Contributor

boelle commented Jan 26, 2020

has anyone been able to reproduce this problem?

@xC0000005
Copy link
Contributor

xC0000005 commented Jan 26, 2020 via email

@boelle
Copy link
Contributor

boelle commented Jan 26, 2020

marlin on a blue pill? thought i have seen it all but oh well :-D

@xC0000005
Copy link
Contributor

xC0000005 commented Jan 27, 2020 via email

@xC0000005
Copy link
Contributor

I pulled the latest Arduino Core, and there's a fix for this issue -
stm32duino/Arduino_Core_STM32#841
Without any other changes, the temp_isr is now firing on the bluepill, and I'll test the M200 soon. @ro-ct , you should probably pick up the latest ST core and see if it doesn't work for you.

@boelle
Copy link
Contributor

boelle commented Jan 27, 2020

I pulled the latest Arduino Core

would vs code not have done that anyway?

@xC0000005
Copy link
Contributor

xC0000005 commented Jan 27, 2020 via email

@boelle
Copy link
Contributor

boelle commented Jan 27, 2020

but is it safe to say that this one if kind of confirmed and also what the fix is?

@ro-ct
Copy link
Author

ro-ct commented Jan 29, 2020

I pulled the latest Arduino Core, and there's a fix for this issue -
stm32duino/Arduino_Core_STM32#841
Without any other changes, the temp_isr is now firing on the bluepill, and I'll test the M200 soon. @ro-ct , you should probably pick up the latest ST core and see if it doesn't work for you.

I followed your advice and downloaded the newest version of the Arduino STM Core directly from github, following this guide. And it works! The watchdog works, the steppers running well (had problems with that as well, probably because of the same timer-issue?) - so everything seems fine so far.
Before that I used the released core version 1.8.0, which I installed with Arduino IDE (board manager).

From my side, this topic can be closed.

Thank you for your help, much appreciated!

@boelle boelle closed this as completed Jan 29, 2020
@github-actions
Copy link

github-actions bot commented Jul 3, 2020

This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.

@github-actions github-actions bot locked and limited conversation to collaborators Jul 3, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
4 participants
@boelle @sjasonsmith @xC0000005 @ro-ct