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.

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

Changes for arduinostm32 4.108 #17970

Closed

Conversation

sjasonsmith
Copy link
Contributor

Description

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

I have only tested this with an SKR Pro, and only on my bench. I don't currently have it in a printer. I have verified that Servo output, flash access, step generation, temperature reading, and SoftwareSerial function. I have not verified every possible function of the hardware.

Unfortunately there are some timer-related issues in the current framework, which prevents us from deleting our SoftwareSerial implementation. I have added comments to the workarounds which will hopefully be able to be removed after the next release.

The two issues in the framework are:

  1. Must call setMode on a timer channel, even if you are using the timer for simple overflows. This prevents the framework's SoftwareSerial from working at all. This has already been fixed, but not yet released:
    HardwareTimer: start timer when only update interrupt needed  stm32duino/Arduino_Core_STM32#849

  2. Setting interrupt priority through SoftwareSerial or HardwareTimer entrypoints doesn't apply the priority to already initialized timers. I have submitted a PR to fix this, but I have a little more work to do and we will then need a new release of the framework.
    Fixed setting HardwareTimer interrupt priority stm32duino/Arduino_Core_STM32#1062

Benefits

Two key benefits:

  1. All HAL/STM32 environments use the same framework version.
  2. We can begin identifying additional issues which may exist as people begin using this.

Related Issues

N/A

@sjasonsmith
Copy link
Contributor Author

This impacts every board using HAL/STM32. I'm hoping people with something other than an SKR Pro will be able to try it out.

I'm actually most interested in whether it is working with Malyan boards, so maybe @xC0000005 or @mojocorp would be interested in trying it out.

With regard to the Malyan M300, it was already using this framework version because that is where the board variant exists. I have to assume that means its timers were not working prior to these changes, and hopefully work now. I might be way off on those assumptions, since I don't have that hardware to test anything with.

@thinkyhead thinkyhead added A: STM32 PR: Improvement T: HAL & APIs Topic related to the HAL and internal APIs. labels May 12, 2020
@thinkyhead
Copy link
Member

thinkyhead commented May 12, 2020

It's good to see that the timers are getting sorted out. You're correct about M300. Compiles fine but then 👎. It will be good to see if this helps or not.

@GhostlyCrowd
Copy link
Contributor

I have a SKR Pro 1.1 in a machine, i just pulled this I'm willing to run a few prints make sure everything is as expected.

Let me know if their is anything specific you want me to do.

@sjasonsmith
Copy link
Contributor Author

I have a SKR Pro 1.1 in a machine, i just pulled this I'm willing to run a few prints make sure everything is as expected.

Let me know if their is anything specific you want me to do.

Just normal use would be great. Heaters, fans, and any other peripherals you normally use.

@sjasonsmith
Copy link
Contributor Author

@thinkyhead I probably should have marked this as a draft, but I don't think I I can change that after-the-fact.

@GhostlyCrowd said in Discord that he might be seeing some issues. We will definitely want testing on this by a few people before it goes in.

@GhostlyCrowd
Copy link
Contributor

GhostlyCrowd commented May 12, 2020

@sjasonsmith
Just to collect my findings in the correct area for every one to see

Ok so the issues ive found is the stepper movement has a slight very slight almost not noticable but you can feel it and see it in the first layer stutter. Its causing micro extrusion issues as well as the first layer you can see slight defect in the outlines. If I place my hands on my 2020 rails on the side of the Y axis you can feel it, it's just an ever so slight sputtering.

Second is the speaker will sometimes function correctly (plays a failure musical tone when I cancel the print) and other times it will just chirp once instead of playing the whole musical tone. Maybe timer silliness?

SKR Pro, TMC2209's, Shut scurve off just top be sure since i know its experimental on Lin adv, still the micro stuttering.

Also reverted a recent merge for pre/post dir delay back to -> #define MINIMUM_STEPPER_POST_DIR_DELAY 20 #define MINIMUM_STEPPER_PRE_DIR_DELAY 20

To be sure it wasn't that.

Attached configs for reference

Config.zip

@sjasonsmith
Copy link
Contributor Author

Thanks @GhostlyCrowd. It is possible the interrupt priority code isn't working quite as expected. I'll have to fixture up my board to verify they are behaving as expected on the logic analyzer.

@mojocorp
Copy link
Contributor

mojocorp commented May 12, 2020

@sjasonsmith I've added the M300 support to stm32duino in 1.8.0 that's why I specified the corresponding ststm32 framework as minimum version in Marlin pio config.
Like I said the regression with the M300 was NOT due to the timers but a bug introduced in the malyan lcd. I fixed it since and it's already merged.
I have no issue at all with my M300. Not sure what problem @thinkyhead is refering.

@sjasonsmith I'm thinking now it's possible there was a problem, or not. I introduced the M300 support to Marlin as soon as ststm32 1.6.0 was released. I'm pretty sure I checked that everything worked at that time. But the thing is, I'm not 100% sure since I'm using my own custom stm32duino to workaround an LTO issue with 1.8.0....So I'm not actually using a stock 1.8.0.

@thinkyhead
Copy link
Member

thinkyhead commented May 12, 2020

probably should have marked this as a draft

The link on the right to do that is small and hard to see, but should be there for the author.

image

@thinkyhead
Copy link
Member

thinkyhead commented May 12, 2020

I have no issue at all with my M300.

Ah, good to hear. I had been having a hard time figuring out M200v2 and M300 build options, which have been a bit of a moving target lately.

on the side of the Y axis you can feel it, it's just an ever so slight sputtering
the speaker will sometimes function correctly

@GhostlyCrowd — I reverted changes aimed at the GTR, some of which may have also been okay for SKR Pro — the assignment of the PWM pins/timers and the MISO pin. Please review this diff to see if there's anything you would want to try:

a06a0c5#diff-443a5c5717b9a729419a33c4a3ded66a

@GhostlyCrowd
Copy link
Contributor

I have no issue at all with my M300.

Ah, good to hear. I had been having a hard time figuring out M200v2 and M300 build options, which have been a bit of a moving target lately.

on the side of the Y axis you can feel it, it's just an ever so slight sputtering
the speaker will sometimes function correctly

@GhostlyCrowd — I reverted changes aimed at the GTR, some of which may have also been okay for SKR Pro — the assignment of the PWM pins/timers and the MISO pin. Please review this diff to see if there's anything you would want to try:

a06a0c5#diff-443a5c5717b9a729419a33c4a3ded66a

Once this test is done ill do a fresh clone and test with #17937

If the micro stutter is not present then that rules it out and ill do more testing with this PR.

@sjasonsmith
Copy link
Contributor Author

@mojocorp that is interesting that M300 timers were working for you. They don’t work in the STM32F4 chips without the setMode call I added. Something changed in the 1.8 framework or its underlying HAL that made that necessary.

@sjasonsmith sjasonsmith reopened this May 12, 2020
@sjasonsmith
Copy link
Contributor Author

The comment and “Close” butters are very close together on a phone 😕

@thisiskeithb
Copy link
Member

thisiskeithb commented May 12, 2020

I'm running a test print with this PR on a BTT002/Prusa MK3S (STM32F4), so I'll let you know how it goes.

Edit: All good here.

@GhostlyCrowd
Copy link
Contributor

GhostlyCrowd commented May 13, 2020

I'm running a test print with this PR on a BTT002/Prusa MK3S (STM32F4), so I'll let you know how it goes.

Edit: All good here.

Can i see your configs and compare them to mine. i want to see why mine is micro stuttering, it appears its a me problem if you're OK, or my specific stepper drivers.

@thisiskeithb
Copy link
Member

Can i see your configs and compare them to mine. i want to see why mine is micro stuttering, it appears its a me problem if you're OK, or my specific stepper drivers.

I keep them online: link. The readme has all my hardware/mods.

@GhostlyCrowd
Copy link
Contributor

Can i see your configs and compare them to mine. i want to see why mine is micro stuttering, it appears its a me problem if you're OK, or my specific stepper drivers.

I keep them online: link. The readme has all my hardware/mods.

Thanks, not difference i can that would cause my micro stuttering.

Let's assume that's a me problem then. however, the Speaker not always working is definitely repeatable it happens 2 out of 3 times for me @sjasonsmith.

I'm going to do some more testing ill let you know. I'm going to make sure the micro stuttering is not mechanical, as this is what it suggests since @thisiskeithb has no issues liek this.

@GhostlyCrowd
Copy link
Contributor

So I did a new flash today, I don't know what or why, but the micro stuttering has gone away chalk it up to something odd on my end.

Speaker is still wonky though. 100% does funky things each time speaker is used it is a dice roll on if it does what its supposed to.

@thisiskeithb
Copy link
Member

Speaker is still wonky though. 100% does funky things each time speaker is used it is a dice roll on if it does what its supposed to.

Can you clarify this?

Does it not play tones, play them incorrectly, cause other hardware to act up, etc.?

@GhostlyCrowd
Copy link
Contributor

GhostlyCrowd commented May 13, 2020

Speaker is still wonky though. 100% does funky things each time speaker is used it is a dice roll on if it does what its supposed to.

Can you clarify this?

Does it not play tones, play them incorrectly, cause other hardware to act up, etc.?

At the end of my print I have a melody using M300 that plays when it finishes. Some times it plays fine, other times it just randomly chirps a handful random tones, like its attempting to do the melody but failing obviously, other times chirps once instead of playing the full melody.

It's definitely this PR that does it too I've rolled back and forth a few times did some cubes to test.

@thinkyhead
Copy link
Member

The comment and “Close” butters are very close together on a phone 😕

Sure, sure, Mister Buttonfingers.

@thinkyhead
Copy link
Member

I received an email about STM32 support in PlatformIO going forward. One of the big changes is the dropping of support for Maple core, so all our PIO targets need to be built on STM32Duino.

Hi Scott, my name is Valerii and I'm responsible for the official development platforms at PlatformIO.

I'm writing to let you know that we plan to release a new major version of the ststm32 platform that will include some breaking changes that might affect the Marlin project:

We're going to drop support for the Maple core. It'll be superseded by the official STM32Duino for all boards (including genericSTM32F1* that's used in Marlin). I'm not sure what are possible consequences of this change for your project, but it looks like there are differences between these cores in terms of API.

tool-stm32duino is going to be updated as well (new package structure, updated binaries, etc). A new tool "STM32CubeProgrammer" will be used for "serial" and "DFU" upload protocols and unfortunately, there is no binary for ARM architecture so it looks like these protocols won't be functional on small computers like Raspberry Pi, etc

Minor change: a new board fysetc_s6 that might conflict with an identical board in your "platformio.ini".

To handle this new release, you can:
Create a separate branch with the development version of ststm32 platform to evaluate new changes, just to make sure that Marlin can be built with the upcoming release.
Fix the platform version to 6.1.0 in the platformio.ini file (maybe just temporarily, to make sure Marlin stays compilable)

@sjasonsmith
Copy link
Contributor Author

I received an email about STM32 support in PlatformIO going forward. One of the big changes is the dropping of support for Maple core, so all our PIO targets need to be built on STM32Duino.

OK, I guess that lessens the urgency of some TONE-related changes I was working on for the STM32F1 HAL, if everything's just going to have to move to the other HAL anyway.

I'll see if I can figure out how to pull down their development version and see how it goes.

Minor change: a new board fysetc_s6 that might conflict with an identical board in your "platformio.ini".

This concerns me. It seems like we end up having to make changes in variants all the time for Marlin, so having the variants already in the framework feels more like a hindrance than a help. I don't know whether it is really going to be practical to use the variants from the framework, or if we will just have to maintain our own Marlin variants anyway, such as MARLIN_FYSETC_S6.

@thinkyhead
Copy link
Member

Well we should definitely prefix things in a standard way to avoid name collisions. I tend to favor MF_, MARLIN_, or marlin_ depending on the situation. That also avoids any confusion about whether we are referring to something internal or external.

@viper93458
Copy link

I am presently using the branch that this PR is derived from. I tried to use the current bugfix 2.0 but its giving my bltouch some troubles. I started using this branch to get around boot loops i was having with my skr pro previously.

By chance is the branch that this PR is coming from fully up to date so i can use it and have all recent bugfix merges too? I apologize for not knowing how to check that myself. I know further work here is pending stm32 1.9 framework still (and probably lots more stuff).

-William

@sjasonsmith
Copy link
Contributor Author

@viper93458 the boot loops were caused by too new of an arduino framework being used. New versions of bugfix should be preventing that, but I haven't actually tried things in a couple weeks.

This PR is currently stalled. There appeared to be some issues related to the I2C EEPROM support that prevented it from moving forward.

At this point we might need some guidance from @thinkyhead regarding how he would like to approach this.

@viper93458
Copy link

viper93458 commented Jun 20, 2020

EEPROM is working great on my SKR pro With your branch as of 5/9/2020. I know there were conversations above about it. I have bltouch issues with current bug fix which don’t happen with your branch so I figured the various changes must be affecting it and was hoping this branch along with current merges would work together to bring me more current. :)

And yes boot loops are gone in current bug fix, but bltouch issues prevent being able to print. :(

Also, eeprom seems to work with current bug fix too. Just as an FYI.

@sjasonsmith
Copy link
Contributor Author

@viper93458 are you using an I2C EEPROM? Default will be either flash or SD EEPROM.

I was able to reproduce the issues others reported with an I2C EEPROM, although I did not spend any time debugging it.

This branch should really not have any advantages over the current bugfix-2.0.x for an SKR Pro. If there are new BLTouch issues in the bugfix-2.0.x branch, that needs investigated. Most likely something got messed up with timer assignments or priorities.

@viper93458
Copy link

Yes, i2c eeprom as reported much earlier in this thread.

@viper93458
Copy link

@viper93458 are you using an I2C EEPROM? Default will be either flash or SD EEPROM.

I was able to reproduce the issues others reported with an I2C EEPROM, although I did not spend any time debugging it.

This branch should really not have any advantages over the current bugfix-2.0.x for an SKR Pro. If there are new BLTouch issues in the bugfix-2.0.x branch, that needs investigated. Most likely something got messed up with timer assignments or priorities.

Agreed, I submitted a bug report: #18372

-William

@sjasonsmith
Copy link
Contributor Author

@thinkyhead
A new platform package has been released for 4.109. My earlier experiments showed this should eliminate several of the workarounds 4.108 required, and may resolve the outstanding I2C EEPROM issue.

I will try updating to the newer framework and update this, for inclusion after the 2.0.6 release. I'm not sure yet whether I will be able to update just the framework version without also updating to a newer platform which might break things.

@thinkyhead
Copy link
Member

…without also updating to a newer platform…

Good luck! I look forward to your results.

@sjasonsmith
Copy link
Contributor Author

I had a FYSETC S6 booting and at least LCD, fans, and Temp ISRs working using ststm32 7.0 with the new framework. Unfortunately I seem to have burned the board up when I added a TMC2208 to test SoftwareSerial. Oops.

I'll have to switch back to my SKR Pro and hope for better results there. I should get to it in the next few days.

@sjasonsmith
Copy link
Contributor Author

sjasonsmith commented Jul 2, 2020

Rather than continuing this PR, I am choosing to drop this one and create a new PR (#18496) for the upgrade to the newer framework.

The changes needed for versions 1.8 and 1.9 were mostly unique, so it didn't seem to make sense to build it on top of this.

@thinkyhead thinkyhead closed this Jul 3, 2020
@thinkyhead
Copy link
Member

Duplicate of #18496

@thinkyhead thinkyhead marked this as a duplicate of #18496 Jul 3, 2020
@sjasonsmith sjasonsmith deleted the PR/STM32_1.8 branch November 23, 2020 09:37
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A: STM32 PR: Improvement T: HAL & APIs Topic related to the HAL and internal APIs.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

10 participants