Generic device support is broken

[cr1901]

The interrupt vector table for a generic application is hardcoded to be 15 entries, which is not universal across all msp430 devices. With this complication, I'm not sure whether a generic application can be made to work at all for msp430.

[minghuaw]

The default 15 entries does not work on MSP430F5529 which requires 23 entries.

[cr1901]

@minghuaw Just circling back to this issue... I think there's 2 problems, for 3 use cases:

Use Cases

1. Create a generic, device-independent application, supplying a generic interrupt vector/exceptions table directly from msp430-rt.
2. Enable the device feature of msp430-rt and manually generate a vector table. See the device example of cortex-m-rt.
3. Use a Peripheral Access Crate (PAC) to automatically fill in a device-specific interrupt vector table, as well as peripherals.

Problems

1. Indeed, there's no set amount of interrupts in the msp430 architecture- the number of interrupts is device specific.
2. Interrupt vectors are at the end of the address space on msp430. Combined with the above, this means that the start address of interrupt vectors is also device-specific.

Comparison to cortex-m-rt

cortex-m-rt does not have the above disadvantages, and creating Cortex-M Rust applications is fairly ergonomic by embedded standards.

Even in a generic application, a memory.x file must be provided during link time by the user. A user must know the start address and length of FLASH and RAM sections of their microcontroller before populating a memory.x file. This is enough information to create a generic application that works on all Cortex-M devices, regardless of vendor or architecture revision.

Because interrupt vectors begin at the beginning of flash, the cortex-m-rt crate uses the previously-provided ORIGIN(FLASH) to place interrupts in their correct position. Once the interrupt vectors are placed, the linker places the .text section immediately after.

As a space/source code size optimization, the length of the interrupt vector table can be shortened from the architecture-mandated value of 240/32 to reclaim flash space (provided those vectors aren't active!).

• The device example in cortex-m-rt and PACs take advantage of the size optimization.
• On the other hand, the generic (device feature disabled) will generate a maximally-sized vector table.

Possible Solutions for MSP430

For now, a user is expected to fill in a VECTORS section in memory.x to provide the start/size of the table.

Generic

Two possible workarounds to make generic applications possible would be:

• Somehow inject the number of interrupts into build.rs (and the start address- see problem 2) for the current device.
• Assume the max amount of interrupts on any msp430 device in production and generate a vector table of the max possible number of interrupts. This wastes precious code space :).

Device Feature, Manual Vectors

I'm not certain if there's a nice way to pass the start and size of the vector table to the linker from Rust code if manually specifying a vector table. A user would need to ensure that the size of their manually-generated vector table matches memory.x's size (and start address, so the reset vector is at 0xfffe)- not very ergonomic compared to cortex-m-rt. Perhaps this can be combined with the PAC proposal below?

PAC

SVD files for msp430 need to be generated from TI DSLite files. Ultimately, the linker script for a given device is the source of truth for the size and start of the vector table.

This information can be passed to svd2rust. When the device feature is enabled, msp430-rt's build.rs could be modified to PROVIDE symbols before include memory.x that specify the start and length of the vector table, which memory.x can then use. I propose modifying svd2rust to support the vendorExtensions field to pass this information.