Changes for arduinostm32 4.108 #17970
Conversation
|
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
added
A: STM32
PR: Improvement
T: HAL & APIs
|
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. |
|
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. |
|
@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. |
|
@sjasonsmith 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 -> To be sure it wasn't that. Attached configs for reference |
|
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. |
|
@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. @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. |
The link on the right to do that is small and hard to see, but should be there for the author.
|
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.
@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: |
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. |
|
@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. |
|
The comment and “Close” butters are very close together on a phone 😕 |
|
I'm running a test print with this PR on a BTT002/Prusa MK3S ( 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. |
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. |
|
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. |
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. |
Sure, sure, Mister Buttonfingers. |
|
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.
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 |
|
Well we should definitely prefix things in a standard way to avoid name collisions. I tend to favor |
|
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 |
|
@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. |
|
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. |
|
@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. |
|
Yes, i2c eeprom as reported much earlier in this thread. |
Agreed, I submitted a bug report: #18372 -William |
|
@thinkyhead 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. |
Good luck! I look forward to your results. |
|
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. |
|
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. |
|
Duplicate of #18496 |
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:
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
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:
Related Issues
N/A