Skip to content

Add stm32wba5 #1229

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.

Sign up for GitHub

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

Jump to bottom
Open
wants to merge 7 commits into
base: master
Choose a base branch
from
Open

Add stm32wba5 #1229

wants to merge 7 commits into from

Conversation

gkobeaga
Copy link

@gkobeaga gkobeaga commented May 11, 2025 •
edited by burrbull
Loading

Related to #1225.

PR to add STM32WBA5 family.

I was not sure how to fill the part table file. On the ST webpage, they appear as three different products: stm32wba50, stm32wba52, stm32wba54-55. First, I wonder if using the dash in 54-55 might cause problems; however, using something like stm32wba5x will cover the other products. Second, they have different product pages, but all of them share the same reference manual stm32wba5xxx, so I am not sure if it is better to group them or leave them as they are.

I haven't modified the nightlies.yaml workflow since wba is included by wb*.

@burrbull
Copy link
Member

There is yet one issue which does not affect on make but cause errors with cargo make.

Files in en.stm32wba5-svd.zip have read-only attributes which blocks deleting them after unpack.

@burrbull
Copy link
Member

ST refers this serie as STM32WBA. Not sure that 5 is needed here.

@gkobeaga
Copy link
Author

ST refers this serie as STM32WBA. Not sure that 5 is needed here.

Right, but then the SVD files are released as STM32WBA5 System View Description only for STM32WBA5x subfamily.

Do you think it is better to use the generic series name STM32WBA, and take a decision in the future depending on how they release the SVD files for STM32WBA6x? Or maybe, leave it as it is as STM32WBA5, to be consistent with the current release name? I thought the latter, I don't mind changing it.

@gkobeaga
Copy link
Author

I can reproduce the error of the CI workflow locally using act. I will try to fix it.

However, I cannot reproduce the issue with cargo_make workflow; the command succeeds. I don't see why the read-only permissions could cause the problem, since the SVD files are extracted using the -j argument for unzip, in the svd directory which has write permissions too. When extracting the files in en.stm32wba5-svd.zip, I don't see different permissions, compared to the files in the other zips. Tell me if I am missing something.

This is the output of act of cargo_make:

[Cargo Make/Cargo Make] ⭐ Run Main Patch SVDs
[Cargo Make/Cargo Make]   🐳  docker exec cmd=[bash -e /var/run/act/workflow/6] user= workdir=
| [cargo-make] INFO - cargo make 0.36.8
| [cargo-make] INFO - Build File: Makefile.toml
| [cargo-make] INFO - Task: patch
| [cargo-make] INFO - Profile: development
| [cargo-make] INFO - Running Task: legacy-migration
| [cargo-make] INFO - Running Task: deps
| makedeps: stm32f0x0
| makedeps: stm32f0x1
| makedeps: stm32f0x2
| makedeps: stm32f0x8
| [cargo-make] INFO - Running Task: extracted
| vendor/en.stm32c0-svd.zip
| vendor/en.stm32f0_svd.zip
| vendor/en.stm32f1_svd.zip
| vendor/en.stm32f2_svd.zip
| vendor/en.stm32f3-svd.zip
| vendor/en.stm32f4-svd.zip
| vendor/en.stm32f7-svd.zip
| vendor/en.stm32g0-svd.zip
| vendor/en.stm32g4_svd.zip
| vendor/en.stm32h5-svd.zip
| vendor/en.stm32h7-svd.zip
| vendor/en.stm32h7rs-svd.zip
| vendor/en.stm32l0-svd.zip
| vendor/en.stm32l1_svd.zip
| vendor/en.stm32l4_svd.zip
| vendor/en.stm32l4plus-svd.zip
| vendor/en.stm32l5-svd.zip
| vendor/en.stm32mp1-svd.zip
| vendor/en.stm32u0-svd.zip
| vendor/en.stm32u5_svd.zip
| vendor/en.stm32wb0-svd.zip
| vendor/en.stm32wb_svd.zip
| vendor/en.stm32wba5-svd.zip
| vendor/en.stm32wl-svd.zip
| vendor/en.stm32wl3-svd.zip
| vendor/stm32n6-svd.zip
| [cargo-make] INFO - Running Task: patch
| patch: stm32f0x0
| patch: stm32f0x1
| patch: stm32f0x2
| patch: stm32f0x8
| [cargo-make] INFO - ==================Time Summary==================
| [cargo-make] INFO - patch:                      57.02%     1.26 seconds
| [cargo-make] INFO - extracted:                  33.06%     0.73 seconds
| [cargo-make] INFO - [Setup Env]:                3.94%      0.09 seconds
| [cargo-make] INFO - [Setup Env - Rust]:         3.26%      0.07 seconds
| [cargo-make] INFO - deps:                       1.90%      0.04 seconds
| [cargo-make] INFO - [Setup Env - Crate Info]:   0.27%      0.01 seconds
| [cargo-make] INFO - [Setup Env - Git]:          0.27%      0.01 seconds
| [cargo-make] INFO - [Load Makefiles]:           0.18%      0.00 seconds
| [cargo-make] INFO - [Setup Env - Vars]:         0.05%      0.00 seconds
| [cargo-make] INFO - legacy-migration:           0.05%      0.00 seconds
| [cargo-make] INFO - [Setup Env - Duckscript]:   0.00%      0.00 seconds
| [cargo-make] INFO - [Setup Env - CI]:           0.00%      0.00 seconds
| [cargo-make] INFO - [Setup Env - Project]:      0.00%      0.00 seconds
| [cargo-make] INFO - ================================================
| [cargo-make] INFO - Build Done in 2.12 seconds.
[Cargo Make/Cargo Make]   ✅  Success - Main Patch SVDs [2.200780524s]

Note: I needed to insert a step in the workflow files to install pyyaml.

@burrbull
Copy link
Member

burrbull commented May 14, 2025 •
edited
Loading

don't see why the read-only permissions could cause the problem, since the SVD files are extracted using the -j argument for unzip, in the svd directory which has write permissions too

The issue is in cargo make extract. Have you tried to do make clean before the check?

stm32wba6 looks like improved version of stm32wba5 with same M33 architecture. So we can you same stm32wba crate for both.

The CI issue is in makecrates.py. See c2b5ebc

There is yet one regex issue in Makefile. CRATES=stm32wb includes stm32wbaxx.yamls. But it should not.
I don't know how to better solve it.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers
No reviews
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.
2 participants
@gkobeaga @burrbull