wb55: fix SYSCFG base address (and Makefile) #473
Conversation
|
Thanks! It looks like the SYSCFG problems run deeper: the reason the SVD has the wrong address is because SYSCFG is split between 4001_0000-4001_002F and 4001_0100-4001_01FF with VREFBUF stuck in the middle. As well as updating the baseAddress as you've done, we should update the addressBlock size to 0x200. Unfortunately it seems all the registers in the 4001_0100 region are wrong in the SVD too (IMR1, IMR2, C2IMR1, C2IMR2, SIPCR) as their offsets ignore the jump over VREFBUF so need updating to 0x100, 0x104, etc. |
|
@adamgreig so the next steps should be joining those two together with the VREFBUF area marked as reserved/skipped to get a contiguous memory map for SYSCFG? |
Yes, I think that's the best way to go. |
|
The same problem exists in the WL family. I'll try to get to it this week and perhaps you can use the same patches here. |
Fixes: stm32-rs#473 Fixes the base address, and then for the registers after the split, fixup their addresses manually. Signed-off-by: Karl Palsson <karlp@etactica.com>
This is likely to be more maintained going forward. Only changes are due to upstream renaming fields in the SVD to be more standard across families, and to more closely match the RefManuals. Depends on either stm32-rs/stm32-rs#624 or stm32-rs/stm32-rs#473 and then a new upstream pac release, so _this_ commit should change to depend on those, but this shows what's needed and how, for preview. Signed-off-by: Karl Palsson <karlp@etactica.com>
Fixes: stm32-rs#473 Fixes the base address, and then for the registers after the split, fixup their addresses manually. Signed-off-by: Karl Palsson <karlp@etactica.com>
624: stm32wb: syscfg: fix split sections r=adamgreig a=karlp Fixes: #473 Fixes the base address, and then for the registers after the split, fixup their addresses manually. Signed-off-by: Karl Palsson <karlp@etactica.com> Is there really any need to specifically mark the VREFBUF as "reserved" within the syscfg block as discussed in #473? is that important? the memory map generated looks correct. Co-authored-by: Karl Palsson <karlp@etactica.com>
This is a batch of two fixes:
SYSCFG. This fix was checked to work in the hardwareMakefileto produce correct directory