[BUG] Restarts after Saving/ Store EEPROM/ M503

shadow578 / Marlin-H32

Marlin for HC32F460 based printers (now in upstream)

http://marlinfw.org

GNU General Public License v3.0

13 stars 7 forks source link

[BUG] Restarts after Saving/ Store EEPROM/ M503 #37

Closed classicrocker883 closed 7 months ago

classicrocker883 commented 1 year ago

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

Yes, and the problem still exists.

Bug Description

When having to save, such as Z-offset, mesh build, or control /advance settings, the LCD screen stops and reboots.

it happens when using BLTouch - Bilinear or UBL bed leveling, or mesh bed leveling.

is this related in the Framework? because this behavior doesn't happen to other chips like G32 or N32.

can this be from something incorrect with flash size? because originally it was limited to 208K. now it can go up to 256K??

Bug Timeline

No response

Expected behavior

Normally, it would just save and the screen not restart

Actual behavior

Screen Restarts, LCD reboots system.

Steps to Reproduce

No response

Version of Marlin Firmware

current

Printer model

No response

Electronics

No response

Add-ons

No response

Bed Leveling

None

Your Slicer

None

Host Software

None

Don't forget to include

[X] A ZIP file containing your Configuration.h and Configuration_adv.h.

Additional information & file uploads

Any possibility are you going to update this repository in the near future? or what other things may be planned regarding this chipset for Voxelab Aquila?

would you be able to help guide me to fix this issue?

shadow578 commented 11 months ago

i've been encountering this issue sporadically too, and it seems to be related to the watchdog timer timing out. could you check these things please:

could you check if anything useful is beign printed to the (host) serial? Like a error message
try disabling the watchdog by commenting #define USE_WATCHDOG in Configuration_adv.h. Please note that disabling the watchdog could have some security implications, so it's best to not leave it disabled
if possible, please try and check if this issue persists with the current arduino core rewrite. for that, you'll have to check out the branches pio-arduino-core-rewite, core-rewrite, and arduino-core-rewrite of the Marlin-H32, framework-arduino-hc32f46x, and framework-hc32f46x-ddl repositories respectively. the arduino core adds a whole bunch of extra debug statements which will make it easier to narrow the problem down. Alternatively, if you provide a configuration i'd be able to compile the firmware for you and provide the firmware.bin

classicrocker883 commented 11 months ago

here is the repo to everything I use for the HC32 to compile.

but if you'd like to compile a .bin I can test it out.

ill be checking out the core-rewrite branch in the mean time and see how that goes.

classicrocker883 commented 11 months ago

/**
 * The watchdog hardware timer will do a reset and disable all outputs
 * if the firmware gets too overloaded to read the temperature sensors.
 *
 * If you find that watchdog reboot causes your AVR board to hang forever,
 * enable WATCHDOG_RESET_MANUAL to use a custom timer instead of WDTO.
 * NOTE: This method is less reliable as it can only catch hangups while
 * interrupts are enabled.
 */
#define USE_WATCHDOG
#if ENABLED(USE_WATCHDOG)
  //#define WATCHDOG_RESET_MANUAL
#endif

what if WATCHDOG_RESET_MANUAL were used?

classicrocker883 commented 11 months ago

after trying the suggested CORE_REWRITE, from all 3 you mentioned, this is what happened.

So before in the earlier version from MAY, the screen would start up normally except BEEP. if I connect to terminal i'm sure it would show some error in the code.

However, in this new core-rewrite that beep has gone away, but the screen freezes immediately after starting.

Another side effect which remains is the SD Card causes a continued loop of rebooting. only when the SD card is removed it then proceeds to start normally.

So the SD card issue causes it to boot loop. The BEEP is gone, that is in the previous (main/default) version it would create a long beep until the SD card is removed. but even so when the SD card is removed, it will still BEEP but just a short one instead continuous.

in the core-rewrite the long continuous and short BEEP is gone, however it freezes once started so I can't say for certain since that is as far as I can go. I cannot test to see if the save issue remains, however that was under DWIN_LCD_PROUI

UPDATE:

Success! well, for JyersUI at least. saving DOES work, saving works as normal. except still SD card issue. could the SD card be on my end? such as having different files and folders causing an issue?

However it would be great to have the PROUI work like it should instead. The PROUI worked for the most part before, except for the save issue - it would restart after saving, and also the SD card inserted causes it to reboot.

How do we go from here so the screen doesnt freeze? because the memory is set to 256k. previously it was once set to 208k, could this be a cause?

shadow578 commented 11 months ago

could you post the serial output for the cases where the screen freezes? Also, does the screen just freeze, or is the whole printer unresponsive?

could the SD card be on my end? such as having different files and folders causing an issue?

it could certainly be that your SD card is formatted in a way that the HAL does not like... Could you tell me what size SD card you're using, how much of the space is used, and the filesystem the card is formatted as?

because the memory is set to 256k. previously it was once set to 208k, could this be a cause?

no, the difference in maximum memory is because previously the memory usage excluded the bootloader, and now it includes it. Since the bootloader is from 0x0 to 0xC000, this causes a difference of ~50k getting reported. In reality, it's still the same space usable.

classicrocker883 commented 11 months ago

the LCD freezes and is unresponsive only when using DWIN_LCD_PROUI. but no matter which UI it does a boot loop with the SD card in. the SD card is 8gb, FAT32, and currently 1.65 GB full. its the card that came with the machine, never had an issue using it for other mainboards with other chip versions.

There was ONE time that everything loaded fine with the SD card in, and the display did not restart over and over in a loop. I dont recall how or what I did to get that, or it could have been using Alex's alexqzd older H32 firmware.

There was an error that popped up after the LCD initialized immediately after flashing, it said EEPROM CNC ERROR

I'll attempt to connect to PC and log output in terminal.

classicrocker883 commented 11 months ago

echo:SD card ok
*** HARDFAULT ***
- FSR / FAR:
SCB->HFSR = 0x40000000
SCB->CFSR = 0x00000100
SCB->DFSR = 0x00000000
SCB->AFSR = 0x00000000
- Bus Fault:
 * IBUSERR
- Stack frame:
R0 = 0x1fffc010
R1 = 0x1fffaf01
R2 = 0x1fffaf01
R3 = 0x1fffc02f
R12 = 0x4006fc00
LR = 0x0003122b
PC = 0x73726574
PSR = 0x60000000
- Misc:
LR = 0xfffffff9
***
1.2

>UID =(0x43323132,0xFF0E5030,0xFFFF732E)
sdio init success!
Print paused at: 21:36:23
Print paused at: 21:36:23
Print paused at: 21:36:23
Print paused at: 21:36:23
Print paused at: 21:36:23
Print paused at: 21:36:23
Print paused at: 21:36:23
Print paused at: 21:36:23
Print paused at: 21:36:23
Print paused at: 21:36:23
Disk init
Tips ------ None Factory file
Tips ------ None Firmware file
GotoApp->addr=0xC000
start
-- clocks dump --
SYS=200000000
HCLK=200000000
PCLK0=200000000
PCLK1=50000000
PCLK2=50000000
PCLK3=50000000
PCLK4=100000000
EXCLK=100000000
F_CPU=50000000
SYSCLK=MPLL,XTAL
P=2
Q=4
R=4
N=50
M=1
--
 Software Reset
Marlin bugfix-2.1.x
echo: Last Updated: 2023-05-13 | Author: Miguel A. Risco-Castillo (MRiscoC)
echo: Compiled: Aug  5 2023
echo: Free Memory: 2387  PlannerBufferBytes: 3456
DWIN handshake IRQ4 auto-assigned to usart rx data available
IRQ5 auto-assigned to usart rx error
IRQ6 auto-assigned to usart tx buffer empty
IRQ7 auto-assigned to usart tx complete
[USART1] begin completed
error.
DWIN handshake
DWIN handshake echo:V87 stored settings retrieved (681 bytes; crc 16632)
//action:notification Stored settings retrieved
[ADC1] initialized device
[ADC1] enable channel 15, sample_time=50
[ADC1] enable channel 14, sample_time=50
HAL_timer_start: temp timer, f=1000
[Timer02A] auto-found cmp= 3125 for fBase=50000000 and prescaler=16
IRQ8 auto-assigned to Timer0
[Timer02A] started with compare value 3125
ADC1] disable channel 5
[ADC1] disable channel 6
[ADC1] disable channel 7
IRQ9 auto-assigned to external interrupt
attachInterrupt: pin=5, irqn=9, mode=2
IRQ10 auto-assigned to external interrupt
attachInterrupt: pin=6, irqn=10, mode=2
IRQ11 auto-assigned to external interrupt
attachInterrupt: pin=7, irqn=11, mode=2
[ADC1] disable channel 13
[ADC1] disable channel 13
[ADC1] disable channel 13
[ADC1] disable channel 13
[ADC1] disable channel 12
HAL_timer_start: step timer, f=122
[Timer02B] auto-found cmp= 25614 for fBase=50000000 and prescaler=16
IRQ12 auto-assigned to Timer0
[Timer02B] started with compare value 25614
IRQ13 auto-assigned to WDT callback
IWatchdog::begin: divider=2048, count_cycle=65536
IWatchdog::begin: timeout=5000ms, actual_timeout=2000ms, base_clock=50000000
//action:prompt_end
BL24CXX Check succeeded!
echo:SD card ok

repeating.....

classicrocker883 commented 11 months ago

I was able to catch output in terminal as it was flashing/ updating the firmware. here is the result, and then rebooted over and over again because the SD card was in

Connecting...
Update firmware at address 14000...
Update firmware at address 16000...
Update firmware at address 18000...
Update firmware at address 1a000...
Update firmware at address 1c000...
Update firmware at address 1e000...
Update firmware at address 20000...
Update firmware at address 22000...
Update firmware at address 24000...
Update firmware at address 26000...
Update firmware at address 28000...
Update firmware at address 2a000...
Update firmware at address 2c000...
Update firmware at address 2e000...
Update firmware at address 30000...
Update firmware at address 32000...
Update firmware at address 34000...
Update firmware at address 36000...
Update firmware at address 38000...
Update firmware at address 3a000...
Firmware update success!
GotoApp->addr=0xC000
start
Printer is now online.
-- clocks dump --
SYS=200000000
HCLK=200000000
PCLK0=200000000
PCLK1=50000000
PCLK2=50000000
PCLK3=50000000
PCLK4=100000000
EXCLK=100000000
F_CPU=50000000
SYSCLK=MPLL,XTAL
P=2
Q=4
R=4
N=50
M=1
--
OTS initialized
 External Reset
Marlin bugfix-2.1.x
echo: Last Updated: 2023-05-13 | Author: Miguel A. Risco-Castillo (MRiscoC)
echo: Compiled: Aug  5 2023
echo: Free Memory: 2387  PlannerBufferBytes: 4096
DWIN handshake IRQ4 auto-assigned to usart rx data available
IRQ5 auto-assigned to usart rx error
IRQ6 auto-assigned to usart tx buffer empty
IRQ7 auto-assigned to usart tx complete
[USART1] begin completed
error.
DWIN handshake
DWIN handshake echo:V87 stored settings retrieved (681 bytes; crc 16632)
//action:notification Stored settings retrieved
[ADC1] initialized device
[ADC1] enable channel 15, sample_time=50
[ADC1] enable channel 14, sample_time=50
HAL_timer_start: temp timer, f=1000
[Timer02A] auto-found cmp= 3125 for fBase=50000000 and prescaler=16
IRQ8 auto-assigned to Timer0
[Timer02A] started with compare value 3125
ADC1] disable channel 5
[ADC1] disable channel 6
[ADC1] disable channel 7
IRQ9 auto-assigned to external interrupt
attachInterrupt: pin=5, irqn=9, mode=2
IRQ10 auto-assigned to external interrupt
attachInterrupt: pin=6, irqn=10, mode=2
IRQ11 auto-assigned to external interrupt
attachInterrupt: pin=7, irqn=11, mode=2
[ADC1] disable channel 13
[ADC1] disable channel 13
[ADC1] disable channel 13
[ADC1] disable channel 13
[ADC1] disable channel 12
HAL_timer_start: step timer, f=122
[Timer02B] auto-found cmp= 25614 for fBase=50000000 and prescaler=16
IRQ12 auto-assigned to Timer0
[Timer02B] started with compare value 25614
IRQ13 auto-assigned to WDT callback
IWatchdog::begin: divider=2048, count_cycle=65536
IWatchdog::begin: timeout=5000ms, actual_timeout=2000ms, base_clock=50000000
//action:prompt_end
BL24CXX Check succeeded!
core entering main loop
echo:SD card ok
*** HARDFAULT ***
- FSR / FAR:
SCB->HFSR = 0x40000000
SCB->CFSR = 0x00000001
SCB->DFSR = 0x00000000
SCB->AFSR = 0x00000000
- Memory Management Fault:
 * IACCVIOL
- Stack frame:
R0 = 0x1fffc408
R1 = 0x1fffb480
R2 = 0x00000004
R3 = 0xfffffffc
R12 = 0x4006fc00
LR = 0x00030629
PC = 0xfffffffc
PSR = 0x80000000
- Misc:
LR = 0xfffffff9
***
1.2

UID =(0x43323132,0xFF0E5030,0xFFFF732E)
sdio init success!
Disk init
Print paused at: 21:50:34
Print paused at: 21:50:34
Print paused at: 21:50:34
Print paused at: 21:50:34
Print paused at: 21:50:34
Print paused at: 21:50:34
Print paused at: 21:50:34
Print paused at: 21:50:34
Print paused at: 21:50:34
Print paused at: 21:50:34
Tips ------ None Factory file
Tips ------ None Firmware file
GotoApp->addr=0xC000
start
-- clocks dump --
SYS=200000000
HCLK=200000000
PCLK0=200000000
PCLK1=50000000
PCLK2=50000000
PCLK3=50000000
PCLK4=100000000
EXCLK=100000000
F_CPU=50000000
SYSCLK=MPLL,XTAL
P=2
Q=4
R=4
N=50
M=1
--
OTS initialized
 Software Reset

repeats from same hardfault as above

classicrocker883 commented 11 months ago

this is the earlier pre-core-rewrite, so not the newest one, but from a few months ago.

this version also works with Manual Mesh. it is able to save using MBL

however UBL or any other ABL bilinear bed mesh leveling, it doesnt save, instead it just restarts everytime you save store settings

Connecting...
Update firmware at address 1a000...
Update firmware at address 1c000...
Update firmware at address 1e000...
Update firmware at address 20000...
Update firmware at address 22000...
Update firmware at address 24000...
Update firmware at address 26000...
Update firmware at address 28000...
Update firmware at address 2a000...
Update firmware at address 2c000...
Update firmware at address 2e000...
Update firmware at address 30000...
Update firmware at address 32000...
Update firmware at address 34000...
Update firmware at address 36000...
Update firmware at address 38000...
Update firmware at address 3a000...
Update firmware at address 3c000...
Update firmware at address 3e000...
Firmware update success!
GotoApp->addr=0xC000
start
Printer is now online.
 External Reset
Marlin ProUI 2.1.3 MRiscoC
Build: 20230805 - 22:01
Author: Miguel A. Risco-Castillo (MRiscoC)echo: Free Memory: 3023  PlannerBufferBytes: 3456
echo:EEPROM version mismatch (EEPROM=V87 Marlin=V88)
//action:notification Hardcoded Default Settings Loaded
echo:Hardcoded Default Settings Loaded
echo:Settings Stored (1066 bytes; crc 18135)
//action:notification Settings Stored
echo:EEPROM Initialized
version 1.2
UID =(0x43323132,0xFF0E5030,0xFFFF732E)
sdio init success!
Disk init
Tips ------ None Factory file
Tips ------ None Firmware file
GotoApp->addr=0xC000
start
 Software Reset
Marlin ProUI 2.1.3 MRiscoC
Build: 20230805 - 22:01
Author: Miguel A. Risco-Castillo (MRiscoC)echo: Free Memory: 3023  PlannerBufferBytes: 3456
echo:V88 stored settings retrieved (1066 bytes; crc 18135)
//action:notification Stored settings retrieved
//action:prompt_end
L24CXX Check succeeded!
echo:SD card ok
version 1.2
UID =(0x43323132,0xFF0E5030,0xFFFF732E)
sdio init fail!
Disk init
Tips ------ None Factory file
Tips ------ None Firmware file
GotoApp->addr=0xC000
start
 Watchdog Reset
Marlin ProUI 2.1.3 MRiscoC
Build: 20230805 - 22:01
Author: Miguel A. Risco-Castillo (MRiscoC)echo: Free Memory: 3023  PlannerBufferBytes: 3456
echo:V88 stored settings retrieved (1066 bytes; crc 18135)
//action:notification Stored settings retrieved
//action:prompt_end
L24CXX Check succeeded!
echo:SD card released
echo: Serial 0 baud rate set to 11520ok

here is UBL version of PROUI, with previous `non-core-rewrite`

?Unable to load mesh data.
?Unable to load mesh data.
version 1.2
UID =(0x43323132,0xFF0E5030,0xFFFF732E)
sdio init fail!
Disk init
Tips ------ None Factory file
Tips ------ None Firmware file
GotoApp->addr=0xC000
start
 Watchdog Reset
Marlin 2.1.3 MRiscoC
echo: Last Updated: Aug  2 2023 | Author: Miguel A. Risco-Castillo (MRiscoC)
echo: Compiled: Aug  2 2023
echo: Free Memory: 3023  PlannerBufferBytes: 3456
Unified Bed Leveling System v1.01 inactive
?Unable to load mesh data.
//action:prompt_end
BL24CXX Check succeeded!
?Unable to load mesh data.
echo:SD card released
echo: Serial 0 baud rate set to 11520ok
>>> M500
SENDING:M500
version 1.2
UID =(0x43323132,0xFF0E5030,0xFFFF732E)
sdio init fail!
Disk init
Tips ------ None Factory file
Tips ------ None Firmware file
GotoApp->addr=0xC000
start
 Watchdog Reset
Marlin 2.1.3 MRiscoC
echo: Last Updated: Aug  2 2023 | Author: Miguel A. Risco-Castillo (MRiscoC)
echo: Compiled: Aug  2 2023
echo: Free Memory: 3023  PlannerBufferBytes: 3456
Unified Bed Leveling System v1.01 inactive
?Unable to load mesh data.
//action:prompt_end
BL24CXX Check succeeded!
?Unable to load mesh data.
echo:SD card released
echo: Serial 0 baud rate set to 11520ok

classicrocker883 commented 11 months ago

echo:V88 stored settings retrieved (1066 bytes; crc 18135)

doesnt appear for the UBL version, this is the one that doesnt allow store/save settings. it starts by saying invalid mesh.

also, I am still not having them read the SD card after flashing, still reboot loops using SD card.

shadow578 commented 11 months ago

*** HARDFAULT ***
- FSR / FAR:
SCB->HFSR = 0x40000000
SCB->CFSR = 0x00000001
SCB->DFSR = 0x00000000
SCB->AFSR = 0x00000000
- Memory Management Fault:
 * IACCVIOL
- Stack frame:
R0 = 0x1fffc408
R1 = 0x1fffb480
R2 = 0x00000004
R3 = 0xfffffffc
R12 = 0x4006fc00
LR = 0x00030629
PC = 0xfffffffc
PSR = 0x80000000
- Misc:
LR = 0xfffffff9
***

ok, it seems like something is going really wrong, because the cpu is trying to execute at 0xfffffffc which is way outside of the flash address range.

could you please upload the firmware.elf file of the build with the issue? It has to be the exact version running on your printer at the time of the crash, so it'd be best if you'd re-compile the firmware, flash it, and cause the crash again.

note: the firmware.elf may contain your windows username, so if you're not comfortable with that you can find the exact line + instruction of the crash using the instructions at https://github.com/shadow578/framework-arduino-hc32f46x/blob/core-rewrite/docs/HardFault.md. Please check both LR and PC in that case.

two more things:

is it correct that between the first (https://github.com/shadow578/Marlin-H32/issues/37#issuecomment-1666672688) and second (https://github.com/shadow578/Marlin-H32/issues/37#issuecomment-1666675326) crash, you've recompiled the firmware? if not, there'd be more than one causes for the crash
are you using a different version of marlin than the one in this repository? If yes, please try and re-create the issue using the version in this repository (core-rewrite branch).

classicrocker883 commented 11 months ago

I'll need a couple days to get this step done.

for question 1. is ti the same firmware between comments: yes I believe they are both the same firmware without recompiling.

yes I was using different one from repository - I simply copied over the core-rewrite over into. however I tested using the original core-rewrite with same results.

shadow578 commented 11 months ago

Ok, take your time.

but on another note, could you also add the output of the link step during the build? Specifically the report of the binary size? i believe there might be a bug in the linker script that could cause code to be placed outside of the flash.

if the report shows that more than 212992 bytes of flash are used, please try to reproduce the issue with a reduced build size, eg. by disabling __DEBUG (and, if needed__CORE_DEBUG) in the hc32.ini.

classicrocker883 commented 11 months ago

so 212992 is the absolute limit for these chips?

I was looking in the other repos which used Eclipse to compile this firmware, they had it limited to 208K, was there a reason for that which could matter now?

how may I output the link step during the build? is it the log in terminal during compile?

shadow578 commented 11 months ago

so 212992 is the absolute limit for these chips?

I was looking in the other repos which used Eclipse to compile this firmware, they had it limited to 208K, was there a reason > for that which could matter now?

212992 Bytes / 1024 = 208 KBytes, so that would be the same.

the chips themselves do support 256 KBytes (or 512 KBytes, depending on model), but the bootloader that handles flashing from sd card takes up ~48 Kbytes.

how may I output the link step during the build? is it the log in terminal during compile?

after compiling the firmware, at the bottom of VSCode there should be a panel listing the compiler logs, which includes the memory usage summary of the link step. it should look something like this:

Memory region         Used Size  Region Size  %age Used
           FLASH:      186848 B       256 KB     71.28%
             OTP:          0 GB       1020 B      0.00%
             RAM:       10800 B       188 KB      5.61%
         RET_RAM:          0 GB         4 KB      0.00%

RAM:   [=         ]   5.6% (used 10800 bytes from 192512 bytes)
Flash: [=======   ]  71.8% (used 188124 bytes from 262144 bytes)

i'm not quite sure if this is also shown when compiling using the marlin autobuild extension, iirc there is a checkbox to enable verbose / detailed / full log output.

alternatively, you can select the 'HC32460 aquila 101' (called different, but can't look it up rn) environment and compile with platformio directly, then it is shown always.

classicrocker883 commented 11 months ago

this is using the most recent core-rewrite source folder and library - platform, arduino/ddl

Verbose-hc32f46x.docx

shadow578 commented 11 months ago

Verbose-hc32f46x.docx

Memory region         Used Size  Region Size  %age Used
           FLASH:      216528B       256 KB    82.60%
             OTP:          0 GB       1020 B      0.00%
             RAM:       12696 B       188 KB      6.59%
         RET_RAM:          0 GB         4 KB      0.00%

ok, so the firmware is actually taking up more than 212992 bytes of flash, meaning some functions and data will be outside of the available flash. if the cpu was to jump to one of these instructions, it'd read garbage (iirc it's 0x00 on every address).

please try to reduce the used flash size to be below 212992 bytes. best way to do this without disabling marlin features is to go into the hc32.ini and removing the __DEBUG and, if (and only if) needed, the __CORE_DEBUG build flags.

this way, some extra code that does error checking in the DDL (for __DEBUG) and the arduino core (for __CORE_DEBUG) are disabled. since each of these checks adds a somewhat large string for the error message, disabling them can save quite a bit of flash.

classicrocker883 commented 9 months ago

GREAT SUCCESS!!

I tested the most recent and this issue is no more.
HOWEVER.......
a new problem emerged.

So the issue before was it would freeze/restart when attempting to save.
NOW:
the issue stems from the SD media card. when the card is inserted, pressing ENTER (ENC encoder button) forces the screen to restart.

everything seems to work fine (WithOUT the SD card in) for the limited time I spent using it, the only unfortunate thing is just that - w/ SD card inserted, pressing the knob button freezes/restart.

shadow578 commented 9 months ago

the issue stems from the SD media card. when the card is inserted, pressing ENTER (ENC encoder button) forces the screen to restart.

could you go into more detail what you mean by "forces the screen to restart"? Does the entire printer restart, or what is happening? If it's not the entire printer restarting, could you provide pictures to make clear what you mean?

additionally, please attach serial output from the time the issue occurs, so from when pressing ENTER after inserting the SD card. if there's a issue causing a reboot, it'll be reported there

classicrocker883 commented 9 months ago

yes let me provide a video. so this happens only with the SD card inserted AND when the encoder knob is pressed. soon as it is pressed it restarts/reboots like being turned on. the screen resets with a loading bar and goes back to the start menu.
edit: I'm certain it is the entire printer restarting, not just the lcd screen. it's almost like... as if the pin that detects or auto mounts the SD card is "grounded" (pulled high/low). I know it's software code related, but how it acts is that.

only with the SD card in which is kind of strange. but without an SD card everything is normal.

classicrocker883 commented 9 months ago

H32-serial-output.zip

here are some files which recorded the terminal output in Pronterface.

they show what happens immediately at startup, and when the fault occurs.

I used two repository types. the one labeled Marlin PROUI is using a UBL bed leveling configuration from this "Marlin-H32" repo.
the second is labeled PROUI using Manual-Mesh (MM) configuration, which uses MRiscoC's repo which I copied over the HC32 files and used the PROUI_EX extra features. I posted both configuration files as well for reference.

some things to note: there seems to be some kind of interference using 115200 vs 250000 baudrate.

Got rubbish reply from COM3 at baudrate 250000:
Maybe a bad baudrate?

echo: Serial 0 baud rate set to 250000
Got rubbish reply from COM3 at baudrate 115200:
Maybe a bad baudrate?

this Marlin-H32 repo (Marlin PROUI without SD) gave a strange issue about that. setting Pronterface com port to 250000 I think made the "rubbish reply" go away, however it would not receive commands from the terminal.
using MRiscoC's PROUI it would only connect using 115200.

another oddity is using MRiscoC's PROUI - with SD card inserted, when it would freeze/restart by pressing the knob, the terminal wouldn't show any HARDFAULT like the other Marlin PROUI repo did.
so to be clear, using Marlin-H32 Marlin PROUI - with SD card inserted, it would always freeze/restart upon loading the main menu. just looping over and over by itself, nothing needs to be pressed in order for that to happen. and it does show in the terminal HARDFAULT, which the other other repo did not.

MRiscoC's PROUI - with SD card inserted would load normally, except ONLY when the knob is pressed THEN the printer will freeze/restart - loading screen back to the main menu.

in pins_Aquila_V101.h

I noticed that

#define EXP_03_PIN PB10
#define EXP_04_PIN PB11

were once PC0 and PC1. if this was working fine before what changed? also it does seem to be working fine now, I'm just curious. but I do think the issue here can have something to do with USART or TX or RX, maybe the added LED_BUILTIN pin. I mean so much has changed since the recent commits in the last week or 2, I wouldn't know where to begin as to what change caused this issue.

on the brightside, the previous issue of it restarting when saving/store eeprom is gone 🥇

shadow578 commented 9 months ago

there seems to be some kind of interference using 115200 vs 250000 baudrate.

i'm assuming you've set the baudrate in marlin to 250000? if so, the 'interference' would be from either the bootloader or the core panicking. the latter can be adjusted in hc32.ini.

looking at Marlin PROUI WITH SD inserted.txt, right at the top of the log is a fault report. please do the following:

pull the latest changes for all repos (platform-hc32f46x, ddl, arduino, marlin)
re-compile marlin from this repo with your existing config
- ensure that the baudrate remains at 115200 baud. it seems like pronterface changes it to 250000
while logging the serial output, reproduce the issue. you will probably see a message 'HARDFAULT' as the issue happens
follow the HardFault guide to find where the fault occurs.
- alternatively, upload the exact firmware.elf file you compiled in step 2
post the results

additionally, you can also use the branch in https://github.com/shadow578/Marlin-H32/pull/50 to get a better fault report. In that case, you'll have to enable POSTMORTEM_DEBUGGING in Configuration_adv.h.

classicrocker883 commented 9 months ago

this is all very good information. I will do this. so I did have everything set to 115200. the odd thing was it gave that error, and switching to 250000 it went away, however it didnt work after that.

is POSTMORTEM_DEBUGGING safe to use? by safe I mean will it perform as it should?

shadow578 commented 8 months ago

it gave that error

what error? if you're talking about the HARDFAULT thing, thats because it outputs at a fixed 11500 baud, so switching the baudrate would hide it. but that wouldn't change the fact that the firmware crashes.

is POSTMORTEM_DEBUGGING safe to use? by safe I mean will it perform as it should?

it should be fairly stable at this point, i'm only ironing out the last (annoyingly stubborn) issues... try it, if it does not work fall back to the 'normal' method.

also, since i was struggeling with debugging faults inside the fault handler, i've written a little tool that might be helpful here too: https://github.com/shadow578/CrashAlyzer/

shadow578 commented 7 months ago

closing since last activity over a month ago

shadow578 / Marlin-H32

[BUG] Restarts after Saving/ Store EEPROM/ M503 #37

Did you test the latest bugfix-2.1.x code?

Bug Description

Bug Timeline

Expected behavior

Actual behavior

Steps to Reproduce

Version of Marlin Firmware

Printer model

Electronics

Add-ons

Bed Leveling

Your Slicer

Host Software

Don't forget to include

Additional information & file uploads

UPDATE:

here is UBL version of PROUI, with previous non-core-rewrite

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

here is UBL version of PROUI, with previous `non-core-rewrite`