`SERIAL_DMA` support for HC32

[shadow578]

Description

this PR adapts the HC32 HAL to make use of some new features in the arduino core and ddl, including support for SERIAL_DMA. It also introduces some extra checks aimed to improve error messages.

Requirements

• any supported HC32-based board.
• updating the packages framework-arduino-hc32f46x and framework-hc32f46x-ddl to their latest release versions (1.1.0 and 2.2.1 respectively).
  • using a older version of framework-arduino-hc32f46x will cause an error prompting the user to update.

Benefits

• general improvements in Serial communication* and support for SERIAL_DMA
• automatic configuration of the arduino core based on Marlins Configuraton.h and Configuration_adv.h
  • e.g. enabling core debugging when enabling MARLIN_DEV_MODE
• fixed support for meatpack

During my testing (about 10 hours of printing as of now), serial errors when host printing were reduced to 0%.

* see https://github.com/shadow578/framework-arduino-hc32f46x/pull/10 for details on the 'general improvements' part

Configurations

sample configuration for Aquila X2 w/ DWIN MarlinUI + BLTouch + SERIAL_DMA

Related Issues

N/A

[classicrocker883]

unrelated to this PR specifically, but HC32 related:
I have run into an issue after flashing the firmware I would get a continual restart loop while the SD card is inserted. once removed it can be used as normal, otherwise anytime the SD card is put in it reboots over and over. is that still an issue?

[shadow578]

unrelated to this PR specifically, but HC32 related: I have run into an issue after flashing the firmware I would get a continual restart loop while the SD card is inserted. once removed it can be used as normal, otherwise anytime the SD card is put in it reboots over and over. is that still an issue?

@classicrocker883 thanks for bringing this issue to my attention. after looking into the sdio HAL, i've noticed that with every initialization of the SDIO (= every time a sd card is inserted), the card handle was leaked. on repeated sd card insertions, this would cause the system to run out of memory and crash.

anyway, i've created a fix and added the commit to this PR (even if it's not related...)

---

EDIT:

just noticed that @classicrocker883's issue occurs on boot. maybe increasing the available heap memory (using DDL_HEAP_SIZE) could help?

if not, it'd probably be best to move the discussion to a issue

[classicrocker883]

just noticed that @classicrocker883's issue occurs on boot. maybe increasing the available heap memory (using DDL_HEAP_SIZE) could help?

if not, it'd probably be best to move the discussion to a issue

as for the value to change what do you suggest? in that link there are two different values presented, default and example. im not sure where to start.

[shadow578]

as for the value to change what do you suggest? in that link there are two different values presented, default and example. im not sure where to start.

the default values are what you'd be using right now, so i'd suggest setting them like so:

[HC32F460_base]
# (...)
build_flags      =
  -D DDL_STACK_SIZE=0x800 -D DDL_HEAP_SIZE=0x2000
  -D ARDUINO_ARCH_HC32
  -D PLATFORM_M997_SUPPORT
# (...)

when everything worked, you should see that the amount of free memory that marlin prints on start increased by ~5120 bytes. so when before you saw "echo: Free Memory: 1800" before the change, after you should see "echo: Free Memory: 6920".

please note that for this to do anything at all, you must use version 2.2.1 of the ddl.

[classicrocker883]

something isnt working with app_config.h, I had to revert hc32.ini and things at least compiled normally.

in that file, I see:

#if ENABLED(POSTMORTEM_DEBUGGING)
  // disable arduino core fault handler, as we define our own
  #define CORE_DISABLE_FAULT_HANDLER 1
#endif

yet this is automatically enabled/defined in hc32.ini

  -D CORE_DISABLE_FAULT_HANDLER             # Disable arduino core fault handler (we use our own)

should POSTMORTEM_DEBUGGING also be enabled or can -D CORE_DISABLE_FAULT_HANDLER be commented out?

[shadow578]

@classicrocker883

something isnt working with app_config.h, I had to revert hc32.ini and things at least compiled normally.

make sure you're using the latest release (at least 1.1.0) of the arduino core.

in that file, I see:

#if ENABLED(POSTMORTEM_DEBUGGING) // disable arduino core fault handler, as we define our own #define CORE_DISABLE_FAULT_HANDLER 1 #endif

yet this is automatically enabled/defined in hc32.ini

-D CORE_DISABLE_FAULT_HANDLER # Disable arduino core fault handler (we use our own)

should POSTMORTEM_DEBUGGING also be enabled or can -D CORE_DISABLE_FAULT_HANDLER be commented out?

this is indeed a change in the default behaviour of the HC32 HAL which i honestly didn't really consider. as per the fault handler documentation, CORE_DISABLE_FAULT_HANDLER will disable the handler built into the arduino core.

so the old behaviour was to just always remove the fault handler, meaning a fault would just lock up the system. with the change, you'll always get a fault report (at the cost of some flash usage).

imo the new behaviour is a better default, as you'll be made aware of the issue.

[InsanityAutomation]

@shadow578 Is this still in a good state in youre opinion? Was looking at getting the Tenlog HC32 board ported in soon and it does seem to call in some of the stuff done here in their fork so figured this would be a prereq.

[shadow578]

@shadow578 Is this still in a good state in youre opinion? Was looking at getting the Tenlog HC32 board ported in soon and it does seem to call in some of the stuff done here in their fork so figured this would be a prereq.

as far as i'm concerned, this should be good to merge and thus in a good state for adapting to a different HC32 board.

but please note that in the end it shouldn't really matter what Tenlog's port "calls in", as the HAL should work for basically every HC32 board with only changes to the config (offset in hc32.ini and pins). i've seen some people trying to port the HAL to different boards and in doing so trying to fork and modify the DDL and stuff. this should not be needed.

[shadow578]

@thisiskeithb sorry for asking, but is there anything preventing the PR from getting reviewed / merged?

[thisiskeithb]

sorry for asking, but is there anything preventing the PR from getting reviewed / merged?

We have nearly 100 open PRs. Please have some patience.

[InsanityAutomation]

I'm not a bare metal side expert on the underlying platforms, so I requested Jason review. I don't see anything that jumps out as wrong to me, but he's the resident expert so I'll leave the review to him