Missing fields in SVD, e.g. WDTPW

[natevw]

It looks as though the SVD file here (and resulting crate) have not been patched with some usual fixups that might be necessary. For one example even after extracting the watchdog example from the very out-of-date MSP430 quickstart HAL code it still doesn't work because the .wdtpw() and .password() methods are missing here.

Digging into the problem it looks like most MSP430 files from TI need some common fixup. E.g. https://github.com/tkuenzel/msp430g2231/blob/ff9fdee6e0f3a0429230d89f0aeb87bf135b14cc/svd_patch/msp430g2231.yaml#L3-L10 is how that PAC ends up with a working WDT setup (and presumedly some other periphs I haven't hit yet). Over at https://github.com/pftbest/msp430_svd/tree/master/overrides/devices there's some built in as well although it's unclear if those get automatically applied or still need manual fixup w/the Python tool regardless.

Note that this isn't a huge blocker for me in practice. I'm doing some initial spinup with an F5529 LaunchPad which is why I keep circling back to this crate, but really targeting a different variant with a custom crate in which I'll likely have to do similar. Once I've worked through that (likely in a closed source fashion to keep things simple with client… not to mention that I've got no business maintaining/supporting a PAC until I'm a lot better at all this 😂) maybe it would be easier for me to contribute something similar to this one on my own time/resources but tbd.

In the meantime figured I'd file this as a known issue if it's easy to address or at least if it helps someone else in a similar boat wondering why the quickstart stuff was quite so far away from working on this device. There's more details over at https://github.com/pftbest/msp430_svd#patching that I found indirectly when trying to track down how the msp430g2231 crate had more of the right fields.

[cr1901]

from the very out-of-date MSP430 quickstart HAL code

Yes, I do need to do a HAL. I have bits and pieces of one locally that's more up-to-date than the quickstart. Fortunately, embedded HAL 1.0 is imminent finally, so there will be less to keep up with.

Unlike PACs, I suspect a HAL will need to be per-family using macros, not per-device; there's simply too much shared code to not do it this way. Of course macros will make the HAL hell to maintain :P.

if those get automatically applied or still need manual fixup w/the Python tool regardless.

You're expected to manually apply the patches in the msp430_svd repo. I should note that svdtools has a Rust version now, and the instructions you link predate that. This could potentially automatically apply patches to the output SVD files.

The msp430g2231 repo just happens to do that step manually outside of the msp430_svd framework (which is perfectly fine IMO- I should still support the manual way of doing things even if I auto-provide some patches).

wondering why the quickstart stuff was quite so far away from working on this device.

Unfortunately, f5529 is a large device with a lot of peripherals. I only had bandwidth to focus on getting g2553 up to date, and constantly reuse my contrived HAL impl in the quickstart for now. Boils down to 2 major reasons:

1. The DSLite files aren't perfect, the same peripheral can be converted to different names (e.g. p1out vs p1_out for a contrived example that I might be misremembering), and I haven't created a pass in msp430_svd to accommodate the different ways a peripheral can be named, let alone how a consistent name may wreak back-compat on existing PACs. Consistent naming of the peripheral registers can be sidestepped with per-device macros in the HAL, but this of course has it's own problems :P.
2. There are definitely a lot of missing f5529 fields, and some of them (like the USB peripheral) are unusable in the PAC as-is, and I haven't come up with a good workaround on how to expose them. Making a patch file takes time, and I dread doing it for f5529 :(.

Current State Of MSP430 Rust

In short, there has not been much progress improving msp430 Rust in 2023. I had a bad experience w/ Rust in early 2023, and I've been burnt out. So msp430 Rust in 2023 has mostly been ensuring my existing code compiles and the target doesn't break until I have more time and bandwidth to improve msp430 again. Yes, I know I've been working on a RISC-V core. I still love msp430.

Me being burnt out is not a reflection of Rust the language or embedded Rust. It's blameless/nobody's fault really. It's just unfortunate. I dove in too deep at once for a helper crate meant to be portable. But Rust portability can still be pretty spotty and I ran into several backend bugs that completely destroyed my momentum on this project.

Not only did the bugs prevent examples from running, I was unhappy with the API of the helper crate as it stands, and wanted to change it. I could not keep up with both needing to redesign the API and the bugs, all of which basically manifested in the course of a week. I realize I needed to stop, take a break, and accept that I was just not going to implement the API that I wanted for the crate and change the already-written documentation to reflect the new API. And go figure, I don't remember the new API I had in mind :P. Not a great feeling...

[cr1901]

I should note that svdtools has a Rust version now, and the instructions you link predate that. This could potentially automatically apply patches to the output SVD files.

@natevw I've went ahead and implemented this. SVD patching, when the relevant overrides/devices file exists, is now done automatically by msp430_svd. I added the watchdog timer fixes for msp430f5529, please try them out (and let me know what other peripherals your application will need).

Please note that I've not updated the PAC crate yet. I'll do that later this week (it's the Most Wonderful Time of the year after all, I'm busy juggling other things before Christmas :P).