Update ststm32 to 8.0 for HAL/STM32

[sjasonsmith]

Description

Update to the latest version of the stm32duino framework, used by HAL/STM32.

Significant Changes

1. Timer code is updated to set priority through the framework
2. SoftwareSerial is now used through the framework
3. Compiler arguments are simplified for USB
   • VID/PID is unchanged, it just occurs by default rather than being explicitly defined
   • Product string defaults to PlatformIO environment name, rather than being explicitly defined
4. FYSETC S6 board/variant is renamed to differ from framework-provided variant
   • The default variant did not work properly for fan PWM
   • Custom script is eliminated, using generic variant creation script instead.
   • It is possible other boards/variants will need changes if fan PWM does not work correctly
5. Malyan M300 now extends from common_stm32.

What have I tested?

• FYSETC S6 (Prior to me accidentally destroying it)
  • Fan PWM
  • BLTouch/Servo control
  • RepRapFullGraphics LCD
  • SPEAKER plays properly
  • Thermistor Reading/Display
  • Flash EEPROM Emulation
• SKR Pro V1.1
  • Fan PWM
  • BLTouch/Servo control
  • RepRapFullGraphics LCD
  • SoftwareSerial with a TMC2208 driver
  • Thermistor Reading/Display
  • Flash EEPROM Emulation
  • Verified proper STEP/TEMP/SoftwareSerial ISR Preemption
• GTR V1.0
  • Fan PWM
  • I2C EEPROM
  • RepRapFullGraphics LCD
  • SoftwareSerial
  • Thermistor
• Malyan M200v2
  • Motion works
  • Thermistors had issues on my board, but I suspect a hardware issue

Benefits

Two key benefits:

1. All HAL/STM32 environments use the same framework version.
2. Provides building block to begin migrating away from Maple for STM32F1 boards

Related Issues

N/A

[sjasonsmith]

I've updated the description to include soem sanity checks I've performed on a GTR V1.0.

[sjasonsmith]

I was able to boot on some Malyan board I have. I messed up my bootloader, but managed to get something on there and write the firmware using a DFU connection over USB.

This appears to be an "M200 v1" board, but has an STM32F070CB (Like the M300). I don't think the pinout exactly matches anything in Marlin right now, but I was able to move a motor and verify that endstop pins work, at least.

[Bob-the-Kuhn]

@rudihorn - I think some of your work on feature request 18157 parallels this PR.

[sjasonsmith]

I’m hoping that this can go in soon after the next tagged release, so people can start building features on top of the latest framework. 1.8 was full of bugs that had to be worked around, but so far 1.9 seems better.

[xC0000005]

If you have an M200 mainboard and it has an 070 MCU on it, it's a V2. There's a very small number of V2s which have F103 processors on them (and an even smaller, like, possibly a handful) of M300 boards that have an 103. Does it reboot after 8 seconds? If not, it's in decent shape.

[sjasonsmith]

@xC0000005 I have an M200 with an 070CB (I think the one in the platformio is an 070RB).
I also have another with an F103, but I haven't even powered that one on yet. These were used boards I picked up cheap on eBay. I destroyed the original board from my Mini a long time ago.

There is a surprisingly huge number of variants of these boards....

[xC0000005]

Six that I know of, possibly more, but they haven’t changed the pinouts since the M100 (and it was likely derived from whatever CNC controller the M100 was extended from). The M300 is a different beast, and the new STM32F4 boards are even more different (but they run an official fork of Marlin). Now that Malyan has released their source, adding support should be easy.

…

On Jul 2, 2020, at 3:45 PM, Jason Smith ***@***.***> wrote: @xC0000005 <https://github.com/xC0000005> I have an M200 with an 070CB (I think the one in the platformio is an 070RB). I also have another with an F103, but I haven't even even powered that one on yet. These were used boards I picked up cheap on eBay. I destroyed the original board from my Mini a long time ago. There is a surprisingly huge number of variants of these boards.... — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#18496 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AHVGS4JRL4LKDM6DWXYGYR3RZUEXDANCNFSM4OOS57QA>.

[sjasonsmith]

Did they release bootloader source by any chance? I accidentally erased mine, and I'm using someone's open-source bootloader I found on github, but I doubt it is capable of updating firmware from SD.

[xC0000005]

Not that I saw, but I’ll share my “recalculate” sketch. If you look at any of the M200 bootlaoders (you can grab the one Mickey uploaded to the marlin 4 mp mini delta project) in a hex editor, at the very end is the string “M200” and a series of bytes. The four bytes after the M200 are a weird byte swapped CRC that is calculated from the CPU ID to tie the boot loader to a batch. If you’re going to run marlin and marlin alone, you can ignore ever patching it - just restore the boot loader. Marlin doesn’t care, and while I knew there was a shared layout section, I never bothered implementing support for it. Also, all the M200 variants really need is the systick turned off before we begin any form of copy over. So, in short - want Marlin only? Just throw the 070 bsotloader on. It’ll calculate the “wrong” CRC but still run. Want to run their stock crap? I’ll share how to patch it.

…

On Jul 2, 2020, at 4:06 PM, Jason Smith ***@***.***> wrote: Did they release bootloader source by any chance? I accidentally erased mine, and I'm using someone's open-source bootloader I found on github, but I doubt it is capable of updating firmware from USB. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#18496 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AHVGS4LKDPWWLD2IJM2Y2RTRZUHG3ANCNFSM4OOS57QA>.

[thisiskeithb]

I'll get my MK3S/BTT002 build running on this and run some test prints this weekend if the PR isn't merged before then.

[sjasonsmith]

I certainly hope this is not merged before the 2.0.6 release, and people test some actual prints with it.

[sjasonsmith]

I just instrumented Marlin and the framework's SoftwareSerial for an SKR Pro to verify that the preemption of ISRs is behaving as expected.
The image below shows the STEP ISR preempting the TEMP ISR, and the SoftwareSerial ISR preempting them both.

This was measured by instrumenting each ISR to set output lines high while active, and capturing the behavior on a logic analyzer.

[GhostlyCrowd]

I've got some hardware changes to do (dual Z stepper and a new lcd) after i get those verified working ill pull this and test on the SKR Pro 1.1 with 5 2209's and BLTouch

[GhostlyCrowd]

Just dropping this in here as per our discussion.

SKR Pro V1.1 no longer passes sanity checks for PWM on extruder auto pans if the speed is set to anything other than 255.

This may be related to STM32 missing

#ifndef digitalPinHasPWM
#define digitalPinHasPWM(P) (PIN_MAP[P].timer_device != nullptr)
#define NO_COMPILE_TIME_PWM
#endif

Which is missing out of STM32 HALL.H, i tried adding it but it still errors so their are deeper issues.

Commenting out static_assert(PWM_PIN(E0_AUTO_FAN_PIN), "E0" AF_ERR_SUFF);

In Marlin/src/inc/sanitycheck.h is a work around

Log Exerpt from VS Code

                 from Marlin\src\HAL\STM32\../shared/Marduino.h:36,
                 from Marlin\src\HAL\STM32\HAL.h:28,
                 from Marlin\src\HAL\STM32\HAL.cpp:25:
C:\Users\JeffJ\.platformio\packages\[email protected]\cores\arduino/pins_arduino.h:254:51: error: non-constant condition for static assertion
  254 | #define digitalPinHasPWM(p)         (pin_in_pinmap(digitalPinToPinName(p), PinMap_PWM))
      |                                     ~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Marlin\src\HAL\STM32\fastio.h:83:33: note: in expansion of macro 'digitalPinHasPWM'
   83 | #define PWM_PIN(P)              digitalPinHasPWM(P)
      |                                 ^~~~~~~~~~~~~~~~
Marlin\src\HAL\STM32\../../inc/SanityCheck.h:2091:19: note: in expansion of macro 'PWM_PIN'
 2091 |     static_assert(PWM_PIN(E0_AUTO_FAN_PIN), "E0" AF_ERR_SUFF);```

[sjasonsmith]

@GhostlyCrowd posted a PR for the SanityCheck issue above, so I won't be spending time on that.
#18539

[sjasonsmith]

There are at least two issues on the Rumba32.

1. Fan PWM is running at only about 38 Hz after I disable FAN_SOFT_PWM
   • Commenting out PWM_FREQUENCY in variant.h allows it to work at 1 kHz (like the SKR Pro)
   • Leaving PWM_FREQUENCY set to 20000 is not working (even though I think it does on the FYSETC S6)
   • I thought I had it working at 20kHz prior to the official 1.9 framework release. Maybe one of the recent changes by @chrissbarr will require a little extra rework with the new framework.
2. SERIAL_TIMER is overridden in the pins file, but that is no longer possible
   • Will need to be overridden in variants.h or platformio.ini
   • A static assert could hopefully be added to the pins file

I haven't done much else with the Rumba32. The following seem to work:

• RepRapDiscount full graphics display
• SPEAKER
• SD card access on the display
• Thermistor reading (indicates temp ISR is running)

[sjasonsmith]

Actually, I take back my comment that I thought I had fan PWM working at 20 kHz earlier on the Rumba32. When I look at my comments on #17519 I am only very clear that I had it working at 1Khz.

[sjasonsmith]

SERIAL_TIMER is overridden in the pins file, but that is no longer possible
Will need to be overridden in variants.h or platformio.ini

This might be a significant issue for boards such as the Rumba32, which are commonly used inside the Arduino IDE. We can more readily control how things build in PlatformIO. I am no expert at building in Arduino, but I assume people would have to go hand edit board definitions or variants to override the default behavior.

The good news is that I have been able to build and upload firmware easily from PlatformIO, at least for my MKS Rumba32. I assume it would work the same for the original Aus3D version.

[GhostlyCrowd]

SERIAL_TIMER is overridden in the pins file, but that is no longer possible
Will need to be overridden in variants.h or platformio.ini

This might be a significant issue for boards such as the Rumba32, which are commonly used inside the Arduino IDE. We can more readily control how things build in PlatformIO. I am no expert at building in Arduino, but I assume people would have to go hand edit board definitions or variants to override the default behavior.

The good news is that I have been able to build and upload firmware easily from PlatformIO, at least for my MKS Rumba32. I assume it would work the same for the original Aus3D version.

I think its about time Marlin drops support for Arduino IDE in my opinion, we have to move forward eventually and it has a laundry list of issues on a good day. their are multiple options to use PIO and VS code is very easy to use for example.

[xC0000005]

I merged this branch with my Lerdge + LCD branch. Thermistors are working, motors “run” but I need to get it installed in a real printer to validate. I had to add a -I to put the HALSTM32 directory back in the include list, other than that it mostly just worked on merge. I2C EEPROM now works where before it hung.

…

On Jul 4, 2020, at 1:21 PM, GhostlyCrowd ***@***.***> wrote: SERIAL_TIMER is overridden in the pins file, but that is no longer possible Will need to be overridden in variants.h or platformio.ini This might be a significant issue for boards such as the Rumba32, which are commonly used inside the Arduino IDE. We can more readily control how things build in PlatformIO. I am no expert at building in Arduino, but I assume people would have to go hand edit board definitions or variants to override the default behavior. The good news is that I have been able to build and upload firmware easily from PlatformIO, at least for my MKS Rumba32. I assume it would work the same for the original Aus3D version. I think its about time Marlin drops support for Arduino IDE in my opinion, we have to move forward eventually and it has a laundry list of issues on a good day. their are multiple options to use PIO and VS code is very easy to use for example. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#18496 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AHVGS4MHA66IRBUJN4WQA53RZ6FNBANCNFSM4OOS57QA>.

[sjasonsmith]

@xC0000005 what is the include path needed for? I had originally added that for SoftwareSerial (which is now gone). Lerdge must need something else?

Feel free to post a PR to my branch if you have any changes that should be included prior to this merging. If it is something that is already broken in the bugfix branch then it could just as easily be a separate PR later.

[xC0000005]

It’s because I’m combining three different PRs together. The tft PR uses it to pick up the right instance of the TFT class. All I did was stick -IMarlin/src/HAL/STM32 into the common STM32 environment flags. Once I do a few prints I’ll report back, and anyone who chooses to test the ledge functionality will be using it, too.

…

On Jul 4, 2020, at 3:06 PM, Jason Smith ***@***.***> wrote: @xC0000005 <https://github.com/xC0000005> what is the include path needed for? I had originally added that for SoftwareSerial (which is now gone). Lerdge must need something else? Feel free to post a PR to my branch if you have any changes that should be included prior to this merging. If it is something that is already broken in the bugfix branch then it could just as easily be a separate PR later. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#18496 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AHVGS4IQIQIZWOKVHZJA6GLRZ6RU3ANCNFSM4OOS57QA>.

[sjasonsmith]

@thinkyhead how would you like to proceed with this?

I'm not sure whether you would plan to squash this in, or merge it with its commit history. If you aren't squashing it I can rebase it and consolidate the changes into a more coherent set of incremental changes.

[sjasonsmith]

After @GhostlyCrowd's report of some BLTouch issues I just did 200 probes without any issues on an SKR Pro. I still suspect perhaps a wiring/connector issue on their printer, unless there is some issue that occurs at power-on that prevents the BLTouch from working?

[GhostlyCrowd]

After @GhostlyCrowd's report of some BLTouch issues I just did 200 probes without any issues on an SKR Pro. I still suspect perhaps a wiring/connector issue on their printer, unless there is some issue that occurs at power-on that prevents the BLTouch from working?

It hasn't happened since i replaced the wiring and the pin as it was bent badly after the last crash, to be safe not sure, what happened but its safe to say its nothing related to this pr

[GhostlyCrowd]

All is well here. Still think this is ready to merge. My issues were my own. Did a repeatability with 200 probes fine. UBL built and verified a mesh fine and I just completed a 16 hour print.

Once this is merged ill test your other PR @sjasonsmith, but Ii don't want to have any regressions since this printer on the SKR Pro is running so beautifully now I have to wait for this to be merged into bugfix.

[sjasonsmith]

@thinkyhead, I've rebased this on top of the latest bugfix-2.0.x and reworked the commit history to give you a concise sequence of changes to look at.

I did some sanity checks on a Malyan M200v2 (STM32F070CB) and verified that at least some of the motors, thermistors, and endstops are working. I didn't test everything due to some limitations testing on my bench.

[sjasonsmith]

I cherry-picked the LCD change from #19297 so that CI can run.

[thinkyhead]

Seems ready to test, and there are not too many relevant changes to sift through if problems do arise.