Getting ".vector_table is shorter than expected" error with MSP430 quickstart + custom memory.x

[natevw]

I'm getting an error

ERROR(msp430-rt): .vector_table is shorter than expected.

when I attempt to compile a dependent of this crate:

= note: c:/ti/msp430-gcc/bin/../lib/gcc/msp430-elf/9.3.1/../../../../msp430-elf/bin/ld.exe:
ERROR(msp430-rt): .vector_table is shorter than expected.
Possible solutions, from most likely to less likely:
- Link to a svd2rust generated pac crate, if you are not
- Fix _sinterrupts in memory.x; it doesn't match the number of interrupts provided by the
pac crate
- Disable the 'device' feature of msp430-rt to build a generic application; a dependency
may be enabling it

collect2.exe: error: ld returned 1 exit status

This is with a memory.x which I believe is correct (enough — n.b. doesn't include all the Flash area…) for this processor?

MEMORY
{
RAM : ORIGIN = 0x2400, LENGTH = 0x2000
ROM : ORIGIN = 0x4400, LENGTH = 0xBB80
VECTORS : ORIGIN = 0xFF80, LENGTH = 0x80
}

/* Stack begins at the end of RAM:
_stack_start = ORIGIN(RAM) + LENGTH(RAM); */

I have tried a cargo clean in case an earlier PAC for a different microprocessor was still interfering. Via https://github.com/cr1901/msp430f5529/issues/1#issuecomment-1577582713 I wondered if this is also because of a conflicting msp430 = "0.4.0" in my app but 0.3.0 in this crate, but I tried downgrading my sample code (which is really just the plain msp430 quickstart at this point) to 0.3.0 as well but the exact same error.

[cr1901]

(This will take me a few days to get back to... I'm trying to get a project out the door before Thanksgiving, tho that's seeming increasingly unlikely lol).

Can you give me a link to your repo with your changes to the quickstart so I can see?

I wondered if this is also because of a conflicting msp430 = "0.4.0" in my app but 0.3.0 in this crate

This isn't strictly wrong, but it's not likely to work. Could I see your example in this state as well (I may need to update some docs w/ the quickstart that msp430 version numbers should match)? The published crate is out of date. I may have locally updated 5529 to use msp430==0.4.0, I'll have to check later. But I haven't had much bandwidth for Rust development other than "making sure msp430 doesn't break" the past few months.

[natevw]

I started a clean project since my work was mixed up with some client-specific notes: https://github.com/natevw/msp430f5529-repro

Unfortunately at least at the moment cargo build fails there for a different (although perhaps related??) issue with all sorts of

…(.vector_table.intterupts+0x7c): undefined reference to SYSNMI

type errors. (TBD if I have time to really chase those down since I'm not getting those in my main project and have found something of a workaround. Basically for now I've just been building against a different chip's PAC but then still deploying to an MSP-EXP430F5529LP anyway and just try avoid anything that would differ/conflict in practice between the actual two variants for now.)

UPDATE: figured out the difference and got rid of the features = ["rt"] line in my [dependencies.msp430f5529] config. Now the sample project as of https://github.com/natevw/msp430f5529-repro/commit/e8c74970d6e776259d7fefc907ca00ca5f6ab5a1 repros the original issue here for me (with msp430-elf 9.3.1 installed from TI's downloads onto a Windows 10 machine.)

[cr1901]

@natevw Okay, so you're running into a cascade of bugs, that aren't necessarily related to each other. For future-me, and just so it's clear what's going on, I'm going to document them here. TL;DR, use this, until I can update msp430f5529 to 0.4.0:

[package]
authors = ["Nathan Vander Wilt <nate@calftrail.com>"]
edition = "2018"
readme = "README.md"
name = "msp430f5529-repro"
version = "0.1.0"

[dependencies]
msp430 = { version = "0.3.0" }
msp430-rt = "0.3.0"
panic-msp430 = "0.3.0"

# Use an existing PAC to ensure examples and the crate itself compiles. If
# targeting a different device, you may need to change the version of your
# crate. Your PAC must be generated with svd2rust version v0.20.0 or later.
[dependencies.msp430f5529]
version = "0.2.0"
features = ["rt"]

# Required for `cargo fix` to work!
[[bin]]
name = "msp430f5529-repro"
test = false
bench = false

[profile.release]
opt-level = "s" # Size is more important than performance on MSP430.
codegen-units = 1 # Better size optimization.
lto = "fat" # _Much_ better size optimization.
# debug = true # Debug _can_ slightly increase size of .text segment.

Remarks

when I attempt to compile a dependent of this crate:

This is a link error. The device feature of msp430-rt is not enabled. This transitively gets enabled by msp430f5529's rt feature.

If you don't enable the device feature, what's supposed to happen is that your interrupt vectors are supposed to be pre-populated with a default handler that infinitely loops. However, because of a bug/oversight that I've never been able to meaningfully solve at compile-time, the size of the interrupt vector array is wrong for f5529. Thus, disabling the device feature is not really meaningfully supported outside of the MSP430Gx families. You wouldn't be able to use per-peripheral interrupts anyway even if it worked. This needs to be documented better, perhaps as a bullet under Possible solutions.

Via https://github.com/cr1901/msp430f5529/issues/1#issuecomment-1577582713 I wondered if this is also because of a conflicting msp430 = "0.4.0" in my app but 0.3.0 in this crate, but I tried downgrading my sample code (which is really just the plain msp430 quickstart at this point) to 0.3.0 as well but the exact same error.

At this point, the same scenario applies; device feature isn't enabled. If I downgrade all 0.4.0 to 0.3.0, I can duplicate this with cargo build [--release]. However, it's funny you should mention that comment, because...

Unfortunately at least at the moment cargo build fails there for a different (although perhaps related??) issue with all sorts of

…(.vector_table.intterupts+0x7c): undefined reference to SYSNMI

The comment accurately describes what's happening here; two versions of msp430-rt are brought in, and only one of them is enabling the device feature:

William@DESKTOP-3H1DSBV MINGW64 ~/Projects/MSP430/msp430f5529-repro
$ cargo tree -e features
msp430f5529-repro v0.1.0 (C:\msys64\home\William\Projects\MSP430\msp430f5529-repro)
├── msp430 feature "critical-section-single-core"
│   ├── msp430 v0.4.1
│   │   └── critical-section feature "default"
│   │       └── critical-section v1.1.2
│   └── critical-section feature "restore-state-u16"
│       └── critical-section v1.1.2
├── msp430 feature "default"
│   └── msp430 v0.4.1 (*)
├── msp430-rt feature "default"
│   └── msp430-rt v0.4.0
│       ├── msp430 feature "default" (*)
│       └── msp430-rt-macros feature "default"
│           └── msp430-rt-macros v0.4.0 (proc-macro)
│               ├── rand v0.8.5
│               │   └── rand_core feature "default"
│               │       └── rand_core v0.6.4
│               ├── proc-macro2 feature "default"
│               │   ├── proc-macro2 v1.0.70
│               │   │   └── unicode-ident feature "default"
│               │   │       └── unicode-ident v1.0.12
│               │   └── proc-macro2 feature "proc-macro"
│               │       └── proc-macro2 v1.0.70 (*)
│               ├── quote feature "default"
│               │   ├── quote v1.0.33
│               │   │   └── proc-macro2 v1.0.70 (*)
│               │   └── quote feature "proc-macro"
│               │       ├── quote v1.0.33 (*)
│               │       └── proc-macro2 feature "proc-macro" (*)
│               ├── rand_xoshiro feature "default"
│               │   └── rand_xoshiro v0.6.0
│               │       └── rand_core feature "default" (*)
│               ├── syn feature "default"
│               │   ├── syn v1.0.109
│               │   │   ├── proc-macro2 v1.0.70 (*)
│               │   │   ├── quote v1.0.33 (*)
│               │   │   └── unicode-ident feature "default" (*)
│               │   ├── syn feature "clone-impls"
│               │   │   └── syn v1.0.109 (*)
│               │   ├── syn feature "derive"
│               │   │   └── syn v1.0.109 (*)
│               │   ├── syn feature "parsing"
│               │   │   └── syn v1.0.109 (*)
│               │   ├── syn feature "printing"
│               │   │   ├── syn v1.0.109 (*)
│               │   │   └── syn feature "quote"
│               │   │       └── syn v1.0.109 (*)
│               │   └── syn feature "proc-macro"
│               │       ├── syn v1.0.109 (*)
│               │       ├── proc-macro2 feature "proc-macro" (*)
│               │       ├── quote feature "proc-macro" (*)
│               │       └── syn feature "quote" (*)
│               ├── syn feature "extra-traits"
│               │   └── syn v1.0.109 (*)
│               └── syn feature "full"
│                   └── syn v1.0.109 (*)
├── msp430f5529 feature "default"
│   └── msp430f5529 v0.2.0
│       ├── bare-metal feature "default"
│       │   └── bare-metal v1.0.0
│       ├── msp430 feature "default"
│       │   └── msp430 v0.3.0
│       │       └── bare-metal feature "default" (*)
│       ├── msp430-rt feature "default"
│       │   └── msp430-rt v0.3.1
│       │       ├── msp430 feature "default" (*)
│       │       └── msp430-rt-macros feature "default"
│       │           └── msp430-rt-macros v0.3.1 (proc-macro)
│       │               ├── rand v0.8.5 (*)
│       │               ├── proc-macro2 feature "default" (*)
│       │               ├── quote feature "default" (*)
│       │               ├── rand_xoshiro feature "default" (*)
│       │               ├── syn feature "default" (*)
│       │               ├── syn feature "extra-traits" (*)
│       │               └── syn feature "full" (*)
│       └── vcell feature "default"
│           └── vcell v0.1.3
├── msp430f5529 feature "rt"
│   ├── msp430f5529 v0.2.0 (*)
│   ├── msp430f5529 feature "msp430-rt"
│   │   └── msp430f5529 v0.2.0 (*)
│   └── msp430-rt feature "device"
│       ├── msp430-rt v0.3.1 (*)
│       └── msp430-rt-macros feature "device"
│           └── msp430-rt-macros v0.3.1 (proc-macro) (*)
└── panic-msp430 feature "default"
    └── panic-msp430 v0.4.0
        └── msp430 feature "default" (*)

The linker script generated by msp430-rt 0.4.0 is winning on the search path, and that path doesn't have a device.x. The linker never sees the linker script fragment or device.x in msp430-rt 0.3.1. Incidentally, when I compile with --release, I get:

$ cargo +nightly build --release -Zbuild-std=core
    Updating crates.io index
   Compiling msp430f5529-repro v0.1.0 (C:\msys64\home\William\Projects\MSP430\msp430f5529-repro)
warning: Linking globals named '__RESET_VECTOR': symbol multiply defined!

error: failed to load bitcode of module "msp430_rt-eecc51f67e5ac9ac.msp430_rt.58b67056c62ddc51-cgu.0.rcgu.o":

warning: `msp430f5529-repro` (bin "msp430f5529-repro") generated 1 warning
error: could not compile `msp430f5529-repro` (bin "msp430f5529-repro") due to previous error; 1 warning emitted

This is a "you have two versions of msp430-rt linked in the same application" error. Even if the interrupt symbols we're found, you would get this error as a result :P. But I wonder why --release skips over the "cannot find interrupt symbols" part? Hmmm...

n.b. doesn't include all the Flash area…

This is expected and normal. Your memory.x is correct. LLVM hasn't learned how to get above 65kB of address space for MSP430 (and AFAICT for gcc, it's not exactly easy either).

[natevw]

@cr1901 Thanks much! I suspect I'll be coming back to read through these notes myself too; quite new to Rust in general and I'm admittedly diving straight into the deep end using it for MSP430, so it's very helpful to see your troubleshooting process detailed out like this. Appreciate the workaround as well.