[BUG] Boot Loop with STM32 on SKR E3 DIP

7FM commented 3 years ago

Did you test the latest `bugfix-2.0.x` code?

Yes, and the problem still exists.

Bug Description

As soon as I am using the STM32 HAL (STM32F103RC_btt, STM32F103RC_btt_USB, STM32F103RE_btt_USB) I am stuck in boot loops, notable by not beeing able to connect via USB and single Bltouch stow and retract between reboots. Using STM32F103RE_btt_maple does not result in a boot loop and allows connection via USB with Octoprint. What I have tried so far:

disable USE_WATCHDOG: doesnt help
enable POSTMORTEM_DEBUGGING: I was only able to connect with openocd when keep holding the reset button. Otherwise I was not able to establish a connection neither with a STLinkv2 nor with a bitbanging RPi ZeroW. I might be doing something wrong here. Any help is welcome, i.e. which pins will provide serial output, is USB emulated serial expected to work for output here too?

Bug Timeline

Seems related to the new STM32 HAL, but support for the enviorments I am using were added just recently so testing earlier commits might be difficult?

Expected behavior

No boot loops :)

Actual behavior

boot loops

Steps to Reproduce

Have an SKR E3 DIP or probaly alike and use my attached config.

Version of Marlin Firmware

Latest commit that I am currently using is: https://github.com/MarlinFirmware/Marlin/commit/3c522fff31f7e1d4127ab09bb27345b098186cd5

Printer model

Ender 3 Pro

Electronics

SKR E3 DIP with TMC2208 drivers, BLTouch & a switch for filament runout detection

Add-ons

No response

Host Software

No response

Additional information & file uploads

My normal config but with MARLIN_DEV_MODE & POSTMORTEM_DEBUGGING enabled and USE_WATCHDOG disabled for testing: MarlinConfig.zip I guess the next steps would be disabling used features one after the other or getting debug to work... Tips and ideas of any kind are welcome :)

rhapsodyv commented 3 years ago

Try disabling ENDSTOP_INTERRUPTS_FEATURE, lets see

Masanetz commented 3 years ago

Tried example configs from Configurations repo. Only commented out #define SD_DETECT_STATE, as it seems to be inverted... It looks like it's a problem with sd-card access. The board boots up without sd-card inserted but goes to bootloop with sd-card. After booting without sd-card, connecting with octoprint, it seems to work until octoprint issues a M21. Then the board reboots.

Using STM32F103RE_btt here. Same config works flawless with STM32F103RE_btt_maple...

Disabling ENDSTOP_INTERRUPTS_FEATURE doesn't work, ether.

7FM commented 3 years ago

The board boots up without sd-card inserted but goes to bootloop with sd-card.

I have tested with and without sd-card and could not (yet) observe such behavior, meaning that I get boot loops in either case. But, there might be several issues overlapping.

Try disabling ENDSTOP_INTERRUPTS_FEATURE, lets see

Did not work for me either but maybe @Masanetz approach is more viable: starting with a bare minimum (which hopefully does not boot loop immediately) and add the currently enabled features one after the other until boot loops occur. This way the possibility of overlapping issues might be reduced. I will also try a bare configuration and will report back later.

7FM commented 3 years ago

Small Update: I have created a very simple config SimpleConfig.zip with STM32F103RC_btt I can connect via USB with Octoprint, however with STM32F103RC_btt_USB no such USB serial appears and thus I can not connect. Even more strange is that it does not seem to boot loop either (firmware.bin is still present on the sd card but does not reflash continuously as it would on resets/boot loops). As SWD still only wants to connect when holding reset, I cant get any info if it is in an error state or operates as "normal" and "just" failed to bring up the USB serial. Is there anywhere code that disables SWD?

Masanetz commented 3 years ago

@7FM please activate SDSUPPORT in Configuration.h and retry. All my problems were related to SDSUPPORT... And please try if STM32F103RE_btt_maple works for you with the same config...

7FM commented 3 years ago

please activate SDSUPPORT in Configuration.h and retry

STM32F103RC_btt_USB:
- with SD inserted: immediate boot loops without user interaction
- without SD inserted: likely the same, no USB serial availble and immediate reflashing when reinsterting the SD card -> reset is performed
STM32F103RC_btt:
- with SD: immediate boot loops without user interaction, USB serial is only available between automatic reflashes caused by reset (really short time frame, needs spamming ls /dev/tty* or tab completion)
- without SD: USB serial is available, however no octoprint connection is possible (timeout). So likely identical behavior as with SD card inserted but without reflashing -> USB serial seems to be availble but due to the boot loops no real connection is possible. Also reinserting the SD card causes reflashing which supports this hypothesis.
STM32F103RE_btt_maple: octoprint successfully connects regardless of whether an SD card is inserted

So yes, SDSUPPORT seems to trigger boot loops with the STM32 HAL. However, there also seems to be another issue with STM32F103RC_btt_USB that no USB serial shows up, regardless of the SDSUPPORT setting.

7FM commented 3 years ago

Also worth mentioning: I have just tested SWD with STM32F103RE_btt_maple and it works as expected and I can connect at any time and not only when holding the reset button. So somewhere in the STM32 HAL must be code that disables SWD! (of course I have used the same config and SDSUPPORT is disabled to avoid boot loops, I even went as far as commenting DISABLE_JTAG which made no difference)

rhapsodyv commented 3 years ago

Ok, when it worked for me I was with ENDSTOP_INTERRUPTS_FEATURE disabled, but without the SD card too! hahaha, so it seems is the SD card.

But, a build with just my LCD and the SD card worked. Probably there's something conflicting with the SD.

The curious part is that there're lots users already using this new envs with success... or we break something recently, or we are using some combination of features that triggers the issue.

And I've been using my jlink for months in STM32 with lots of different boards... But I can't connect it in my SKR MINI E3 V2 too... something is really not right...

I will take a deep look.

rhapsodyv commented 3 years ago

Try removing -DHAL_SD_MODULE_ENABLED from the [env:STM32F103RE_btt]. I will send a PR later.

7FM commented 3 years ago

Try removing -DHAL_SD_MODULE_ENABLED from the [env:STM32F103RE_btt]. I will send a PR later.

did not work for me, still getting boot loops with the minimal configuration and SDSUPPORT and env:STM32F103RE_btt as target

rhapsodyv commented 3 years ago

Hum... for me, it worked... Let me check if I disabled anything else.

7FM commented 3 years ago

env:STM32F103RC_btt never had this flag set and has the same issues as env:STM32F103RE_btt but I am also not sure what the exact differences are besides the larger ROM for the RE version

rhapsodyv commented 3 years ago

HAL_SD_MODULE_ENABLED should me used only when the board uses SDIO. For SD SPI, we need disable it.

rhapsodyv commented 3 years ago

my build_flags for [env:STM32F103RE_btt] is now: build_flags = ${common_stm32.build_flags} -DSS_TIMER=4 -DTIMER_SERVO=TIM5

Try it.

Note: I'm using SKR MINI E3 V2 (RC) (I don't have E3 DIP - RE)... But compiling and RE, as RC and RE are the same chip but with different flash size.

7FM commented 3 years ago

build_flags = ${common_stm32.build_flags} -DSS_TIMER=4 -DTIMER_SERVO=TIM5

still no luck for me (tried both environments), could you share your configs? I do not have an LCD but I guess this should not matter in this case.

rhapsodyv commented 3 years ago

It's your configs with LCD and my board:

Archive.zip

7FM commented 3 years ago

Hmm, ok. I am currently using for this testing the mentioned simple config with most features disabled. Let me double check with a fresh Marlin bugfix clone and the different configs.

7FM commented 3 years ago

Nope, definitely still boot looping

rhapsodyv commented 3 years ago

So it seems a thing related with the pins file. Let me check it

rhapsodyv commented 3 years ago

Try add this to your pins file:

#define SDSS                              PA4

7FM commented 3 years ago

Interesseting without SD card I am now getting the behavior described by @Masanetz: No boot loop but crash at M21

Recv: Cap:SERIAL_XON_XOFF:0
Recv: Cap:BINARY_FILE_TRANSFER:0
Recv: Cap:EEPROM:1
Recv: Cap:VOLUMETRIC:1
Recv: Cap:AUTOREPORT_POS:0
Recv: Cap:AUTOREPORT_TEMP:1
Recv: Cap:PROGRESS:0
Recv: Cap:PRINT_JOB:1
Recv: Cap:AUTOLEVEL:1
Recv: Cap:RUNOUT:1
Recv: Cap:Z_PROBE:1
Recv: Cap:LEVELING_DATA:1
Recv: Cap:BUILD_PERCENT:0
Recv: Cap:SOFTWARE_POWER:0
Recv: Cap:TOGGLE_LIGHTS:0
Recv: Cap:CASE_LIGHT_BRIGHTNESS:0
Recv: Cap:EMERGENCY_PARSER:1
Recv: Cap:HOST_ACTION_COMMANDS:1
Recv: Cap:PROMPT_SUPPORT:1
Recv: Cap:SDCARD:1
Recv: Cap:REPEAT:0
Recv: Cap:SD_WRITE:1
Recv: Cap:AUTOREPORT_SD_STATUS:0
Recv: Cap:LONG_FILENAME:0
Recv: Cap:THERMAL_PROTECTION:1
Recv: Cap:MOTION_MODES:0
Recv: Cap:ARCS:1
Recv: Cap:BABYSTEPPING:1
Recv: Cap:CHAMBER_TEMPERATURE:0
Recv: Cap:COOLER_TEMPERATURE:0
Recv: Cap:MEATPACK:0
Recv: ok N1 P31 B31
Send: M21
Recv: 
Recv: 
Recv: ## Software Fault detected ##
Recv: Cause: Hard
Recv: R0   : 0x08034AC8
Recv: R1   : 0x00000001
Recv: R2   : 0x00000000
Recv: R3   : 0x00008000
Recv: R12  : 0x20001E9A
Recv: LR   : 0x0802B11B
Recv: PC   : 0x0802B11C
Recv: PSR  : 0x21000000
Recv: CFSR : 0x00000000
Recv: HFSR : 0x40000000
Recv: DFSR : 0x00000000
Recv: AFSR : 0x00000000
Recv: MMAR : 0xE000ED34
Recv: BFAR : 0xE000ED38
Recv: ExcLR: 0xFFFFFFF9
Recv: ExcSP: 0x2000FF40
Recv: Backtrace:#1 : unknown@0x0802B0FC+32 PC:0x0802B11C
Recv: #2 : unknown@0x0802C71C+38 PC:0x0802C742
Recv: #3 : unknown@0x08016F60+1470 PC:0x0801751E
Recv: #4 : unknown@0x08017774+246 PC:0x0801786A
Recv: #5 : unknown@0x080197D0+126 PC:0x0801984E
Recv: #6 : unknown@0x08011FC0+88 PC:0x08012018
Recv: #7 : unknown@0x08009522+14 PC:0x08009530
Recv: #8 : unknown@0x080095F8+50 PC:0x0800962A

Try add this to your pins file:

define SDSS PA4

will do

7FM commented 3 years ago

define SDSS PA4

seems to work, will test the _USB env next!

rhapsodyv commented 3 years ago

I will send a PR

7FM commented 3 years ago

The other bugs remain:

with STM32F103RC_btt_USB and STM32F103RE_btt_USB no USB serial appears.
neither for the _USB nor the non USB envs does SWD work

rhapsodyv commented 3 years ago

I think I found the issue with SWD. It seems maple start the variant with SWD register in the reset state, allowing us to use it. But STM32 not.

So, try this: File: Marlin/src/MarlinCore.cpp, Line: ~ 1130

  #if EITHER(DISABLE_DEBUG, DISABLE_JTAG)
    // Disable any hardware debug to free up pins for IO
    #if ENABLED(DISABLE_DEBUG) && defined(JTAGSWD_DISABLE)
      JTAGSWD_DISABLE();
    #elif defined(JTAG_DISABLE)
      JTAG_DISABLE();
    #else
      #error "DISABLE_(DEBUG|JTAG) is not supported for the selected MCU/Board."
    #endif
  #else
    AFIO_DBGAFR_CONFIG(AFIO_MAPR_SWJ_CFG_RESET); // FULL SWD+JTAG
  #endif

I added the #else part. See if it make SWD working for you.

7FM commented 3 years ago

I think I found the issue with SWD. It seems maple start the variant with SWD register in the reset state, allowing us to use it. But STM32 not.

So, try this: File: Marlin/src/MarlinCore.cpp, Line: ~ 1130
  #if EITHER(DISABLE_DEBUG, DISABLE_JTAG)
    // Disable any hardware debug to free up pins for IO
    #if ENABLED(DISABLE_DEBUG) && defined(JTAGSWD_DISABLE)
      JTAGSWD_DISABLE();
    #elif defined(JTAG_DISABLE)
      JTAG_DISABLE();
    #else
      #error "DISABLE_(DEBUG|JTAG) is not supported for the selected MCU/Board."
    #endif
  #else
    AFIO_DBGAFR_CONFIG(AFIO_MAPR_SWJ_CFG_RESET); // FULL SWD+JTAG
  #endif
I added the #else part. See if it make SWD working for you.

currently in most pin_*.h files DISABLE_JTAG is set so this #else section would not be reachable. Thus, for testing I will move move it above #if EITHER(DISABLE_DEBUG, DISABLE_JTAG) such that it is always set and the subsequent calls reduce the debug availability as desired.

7FM commented 3 years ago

With the AFIO_DBGAFR_CONFIG statement moved as described, SWD works again :) Great work!

rhapsodyv commented 3 years ago

Is that, for F1 boards, you need to comment out DISABLE_DEBUG to be able to use SWD.

That's good. I will add the SWD fix to my PR and next I will test the serial :-)

Let me know if find anything else!

7FM commented 3 years ago

Is that, for F1 boards, you need to comment out DISABLE_DEBUG to be able to use SWD.

the E3 DIP does not have this flag set, just DISABLE_JTAG which is bit more fine grain as it still allows the SWD usage. That's why I moved the config reset statement up. Otherwise this granuality is lost for STM32 users, as both DISABLE_JTAG and DISABLE_DEBUG would be required to be commented out, even if the board provides dedicated pins for SWD which are not reused for other purposes such as i.e. stepper driver control.

EDIT: saw the commit in your PR, LGTM!

next I will test the serial :-)

Good luck :-) As always, I am available for testing!

rhapsodyv commented 3 years ago

The serial issue may take longer to fix, because I can't debug when using my serial in this board (because of USB_CONNECT_PIN PA14).

I will need to setup my JTAG to be able to see what is happening.

This is the PR I'm adding the fixes: #22087

rhapsodyv commented 3 years ago

@7FM can you test this PR? It should fix the serial and media share for _USB env: #22116

7FM commented 3 years ago

Looks good! I can successfully connect with Octoprint and also simultaneously mount the shared media :) But haven't run any prints so far. I will consider this solved and open a new issue if I experience any further problems. Again, great work and thx!

github-actions[bot] commented 3 years ago

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.

MarlinFirmware / Marlin