8000 STM32: Set correct crystal settings on Discovery boards by hierophect · Pull Request #2979 · adafruit/circuitpython · GitHub
[go: up one dir, main page]

Skip to content
< 8000 div hidden="hidden" data-view-component="true" class="js-stale-session-flash stale-session-flash flash flash-warn flash-full"> Dismiss alert

STM32: Set correct crystal settings on Discovery boards #2979

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

Merged
merged 2 commits into from
Jun 1, 2020
Merged

STM32: Set correct crystal settings on Discovery boards #2979

merged 2 commits into from
Jun 1, 2020

Conversation

hierophect
Copy link
Collaborator

During the implementation of low power mode a couple of Discovery boards were mistakenly marked as having low power crystals, but actually only have DNP slots that require the user to install them. This resulted in these dev boards being unable to boot fully due to infinite loops on failure in some of the STM32 HAL functions.

This PR sets the Discovery boards crystal settings based on their manual data, which should help with the boot problems. Unfortunately, I don't have most of the Disco boards on my desk at the moment so any help testing these changes would be appreciated.

@hierophect hierophect requested review from tannewt and k0d May 29, 2020 18:07
Copy link
@k0d k0d left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@hierophect I've checked the 2 boards I have. The disco is fine, the nucleo is not correct. Could you give me details though about how to do a real low-power test so that I can be sure everything is fine.

@hierophect
Copy link
Collaborator Author

@k0d right now we're just looking for correct boot behavior. See here: #2952

k0d
k0d previously approved these changes Jun 1, 2020
@k0d
Copy link
k0d commented Jun 1, 2020

@hierophect#2551 Not sure what you're doing with this PR, what's wrong with the LSE on H7/F7?

@hierophect
Copy link
Collaborator Author
hierophect commented Jun 1, 2020

@k0d @tannewt Unfortunately, it looks like I can't mess with the settings on the F7 or H7s without messing up their boot behavior. I thought it was just the Nucleos after my first round of testing but now I'm having issues on the H746 discovery as well.

What these boards need is a full implementation of the low power domain initialization code for the H7 and F7. I can work on that this week but for now I've made a TODO comment for each of them so this can at least still be submitted as a hotfix for the Discovery F4.

@hierophect
Copy link
Collaborator Author

@k0d Right now, the new low power code in port.c has some caused problems with certain combinations of settings that cause boards to fail to boot if their oscillator settings don't match the actual board or the settings in clocks.c. Specifically, each board using an external LSE needs to have the backup domain configured properly or it won't exit the boot stage. I tried to make the system cleanly fall back to an internal oscillator if it fails, but my testing is showing it isn't working as it should be, at least not reliably.

Unfortunately this does make this PR a bit anemic as-is... it does at least fix the Discovery F4, which is why I made it in the first place. But perhaps I should just rework it completely into a general low power settings fix across all boards.

Copy link
Member
@tannewt tannewt left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is a good interim fix for these boards while we sort out the crystal init. Merging for the next beta. Thanks!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants
0