Skip to content

fix fpu double interrupt for new devices #361

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

Open
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

marcoieni
Copy link
Contributor

As detailed in issue #352, a lot of microcontrollers svd have a duplicated FPU interrupt entry.

This problem has already been fixed for all the existing microcontrollers in #357.
This commit apply the same fix to all the new microcontrollers that need it.

As detailed in issue stm32-rs#352, a lot of microcontrollers svd have a duplicated
FPU interrupt entry.

This problem has already been fixed for all the existing microcontrollers.
This commit apply this fix to all the new microcontrollers that need it.
@adamgreig
Copy link
Member

Thanks for splitting the previous PR out and doing this one separately.

I think it's important to note that this PR is really creating six new devices, not just fixing the FPU interrupt on them -- they don't exist at all yet. Do you know anything about these parts? We currently have e.g. stm32l4x5 which one might hope would cover stm32l4r5 and stm32l4s5, but I see ST provide a separate SVD file. If it's possible to cover them using the l4x5 SVD, that would be better.

If not, and we really do need to add six new devices to the L4 family, we can definitely do that - but this PR should be called "Add new STM32L4 devices", they'd probably want a number of extra patches and peripherals (perhaps starting on what we've already got in the L4x5 devices), and they'd need adding to stm32_part_table.yaml.

@marcoieni
Copy link
Contributor Author

Do you know anything about these parts?

No, I just noticed this double interrupts with a simple grep command on all the svd files.

If it's possible to cover them using the l4x5 SVD, that would be better.

I ran svd mmap with stm32l4x5.svd vs stm32l4r5.svd and stm32l4x5.svd vs stm32l4s5.svd and they look very different, so maybe it is better to use the svd files provided by ST. If we decide to go in this direction I will rename this PR and I will update the stm32_part_table.yaml.

they'd probably want a number of extra patches and peripherals

Ok, but I have to figure out those in this PR or they could be submitted in the future in another PR?

@marcoieni marcoieni mentioned this pull request Apr 25, 2020
15 tasks
@newAM newAM added the stm32l4 label Nov 10, 2021
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