Conversation
zfields
force-pushed
the
blues-swan
branch
3 times, most recently
from
5aad8bf to
1fe4411
Compare
- improve comment accuracy - macro variable rename
github-project-automation
bot
moved this from In progress
to Reviewer approved
in STM32 core based on ST HAL
There was a problem hiding this comment.
Pull request overview
This PR targets the Blues SWAN_R5 board initialization to ensure the 3V3 regulator discharge pin is configured correctly (open-drain) at startup, addressing issue #2954. It also includes broader variant maintenance changes for SWAN_R5 pin mappings and clock configuration documentation, plus a small cleanup/fix for the Blues CYGNET variant.
Changes:
- Fix SWAN_R5 3V3 regulator initialization by configuring the DISCHARGE pin as open-drain (OD) rather than push-pull (PP).
- Restructure SWAN_R5 variant pin definitions /
digitalPin[]layout and annotate mappings more explicitly. - Cleanup CYGNET VMAIN divider macro naming and refine clock-config documentation/comments.
Reviewed changes
Copilot reviewed 6 out of 6 changed files in this pull request and generated 3 comments.
Show a summary per file
| File | Description |
|---|---|
variants/STM32L4xx/.../variant_SWAN_R5.h |
Reworks SWAN_R5 pin defines and adds board/regulator/VMAIN helper macros. |
variants/STM32L4xx/.../variant_SWAN_R5.cpp |
Updates digitalPin[] / analogInputPin[]; fixes regulator init (PE6 open-drain); expands clock-config commentary. |
variants/STM32L4xx/.../PeripheralPins_SWAN_R5.c |
Converts to a “manually generated” pin map with schematic reference and many comment clarifications/adjustments. |
variants/STM32L4xx/.../variant_CYGNET.h |
Renames/fixes VMAIN divider constant usage (VMAIN_ADC_DIV_K). |
variants/STM32L4xx/.../variant_CYGNET.cpp |
Documentation/reference cleanup in clock config; minor struct field/comment adjustments. |
variants/STM32L4xx/.../PeripheralPins_CYGNET.c |
Adds schematic link comment. |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
| // Digital PinName array | ||
| const PinName digitalPin[] = { | ||
| PD_9, | ||
| PD_8, | ||
| PF_15, | ||
| PE_13, | ||
| PE_3, | ||
| PE_11, | ||
| PE_9, | ||
| PF_13, | ||
| PF_12, | ||
| PD_15, | ||
| PA_4, | ||
| PA_7, | ||
| PA_6, | ||
| PA_5, | ||
| PB_9, | ||
| PE_1, | ||
| PA_3, | ||
| PA_1, | ||
| PC_3, | ||
| PC_1, | ||
| PC_4, | ||
| PC_5, | ||
| PB_1, | ||
| PC_2, | ||
| PA_0, | ||
| PA_10, | ||
| PA_9, | ||
| PG_12, | ||
| PB_4, | ||
| PD_6, | ||
| PA_2, | ||
| PD_4, | ||
| PD_3, | ||
| PB_10, | ||
| PB_11, | ||
| PD_2, | ||
| PB_13, | ||
| PG_8, | ||
| PG_7, | ||
| PB_7, | ||
| PB_6, | ||
| PF_0, | ||
| PF_1, | ||
| PC_9, | ||
| PC_0, | ||
| PD_0, | ||
| PB_15, | ||
| PB_14, | ||
| PD_1, | ||
| PD_5, | ||
| PE_10, | ||
| PC_11, | ||
| PE_12, | ||
| PB_0, | ||
| PE_14, | ||
| PE_15, | ||
| PE_2, | ||
| PC_13, | ||
| PE_4, | ||
| PA_11, | ||
| PA_12, | ||
| PC_6, | ||
| PE_6, | ||
| PG_0, | ||
| PG_1, | ||
| PG_2, | ||
| PG_3, | ||
| PB_2, | ||
| PH_3, | ||
| PB_3, | ||
| PA_15, | ||
| PA_14, | ||
| PA_13, | ||
| PC_14, | ||
| PC_15 | ||
| PD_9, // 0 - D0 | ||
| PD_8, // 1 - D1 | ||
| PF_15, // 2 - D2 | ||
| PE_13, // 3 - D3 | ||
| PE_3, // 4 - D4 |
There was a problem hiding this comment.
The PR description/issue scope is about fixing the Swan 3V3 regulator init, but this change also reorders the entire digitalPin[] array (and thus board pin numbering) for SWAN_R5. That is a potentially breaking API change for any sketches/libraries that refer to numeric pin IDs beyond the standard D0..D15/A* aliases. If this renumbering is intentional, it should be explicitly called out (or split into a separate PR) and ideally accompanied by a compatibility strategy (e.g., preserve prior numbering or provide transitional aliases/documentation).
| #ifdef HAL_SD_MODULE_ENABLED | ||
| WEAK const PinMap PinMap_SD_DATA4[] = { | ||
| {PB_8, SDMMC1, STM_PIN_DATA(STM_MODE_AF_PP, LL_GPIO_PULL_UP, GPIO_AF12_SDMMC1)}, // SDMMC1_D4 | ||
| {PB_8, SDMMC1, STM_PIN_DATA(STM_MODE_AF_PP, LL_GPIO_PULL_UP, GPIO_AF12_SDMMC1)}, // SDMMC1_D4 - D1 |
There was a problem hiding this comment.
The comment on PB_8 labels it as D1, but in the SWAN_R5 variant pin map D1 is PD8 (see variant_SWAN_R5.h), and PB8 is not defined as a board digital pin. This looks misleading for anyone trying to enable SDMMC later; please correct the comment (or remove the mapping entirely if PB8 is not actually routed on the board).
| {PB_8, SDMMC1, STM_PIN_DATA(STM_MODE_AF_PP, LL_GPIO_PULL_UP, GPIO_AF12_SDMMC1)}, // SDMMC1_D4 - D1 | |
| {PB_8, SDMMC1, STM_PIN_DATA(STM_MODE_AF_PP, LL_GPIO_PULL_UP, GPIO_AF12_SDMMC1)}, // SDMMC1_D4 |
| PC_4, // 21 - A4 | ||
| PC_5, // 22 - A5 | ||
| PB_1, // 23 - A6 | ||
| PD_1, // 24 - CK |
There was a problem hiding this comment.
Minor consistency: digitalPin[24] is commented as CK, but the variant header and SPI definitions refer to this pin as SCK (PIN_SPI_SCK / PD1). Consider updating the comment to SCK to avoid confusion when cross-referencing pin maps.
| PD_1, // 24 - CK | |
| PD_1, // 24 - SCK |
Addresses #2954
Also: Minor clean-up of Blues Cygnet