pftbest / msp430_svd Goto Github PK

Leaving this here for later. According to ARM's Schema for SVD:

registers section contains all registers owned by the peripheral. In case a peripheral gets derived it does not have its own registers section, hence this section is optional. A unique peripheral without a registers section is not allowed

The way we generate interrupts currently is to create a single interrupts peripheral which contains all the device interrupts, a base address, and no registers. svd2rust accepts this, but it is technically out of spec.

Because SVD by itself doesn't have a good way to encode the interrupt start address, I believe vendorExtensions is a good place to put this information. I plan to discuss this with the svd2rust maintainers re: what a vendorExtensions section should look like.

Attempt to generate an svd for msp430f2619 trigger panicking with following backtarce:

0: rust_begin_unwind
at /rustc/11ebe6512b4c77633c59f8dcdd421df3b79d1a9f/library/std/src/panicking.rs:575:5
1: core::panicking::panic_fmt
at /rustc/11ebe6512b4c77633c59f8dcdd421df3b79d1a9f/library/core/src/panicking.rs:65:14
2: msp430gen::dslite_parser::parse_dslite
at ./src/dslite_parser.rs:88:17
3: msp430gen::main
at ./src/main.rs:43:22
4: core::ops::function::FnOnce::call_once
at /rustc/11ebe6512b4c77633c59f8dcdd421df3b79d1a9f/library/core/src/ops/function.rs:251:5

You can run the tool for each MCU in the database using this command:

for i in msp430-gcc-support-files/targetdb/devices/*.xml; do j=${i%.*}; k=${j##*/}; echo $k; cargo run --release $k >/dev/null; done

and look for panics.

According to the datasheet, MSP430FR2355 has only 6 GPIO ports. However, the XML description in the repo has ports P1 to P10. This leads to incorrect SVD files being generated, leading to incorrect PAC crates. I got the device XML file from CCS8, so I have no clue why it doesn't match with the datasheet. Will fix it once I figure it out.

@pftbest Have you ever seen something like this?

E:\downloads\chrome\msp430_svd-master\clone\msp430_svd>cargo run -- msp430f47187 > msp430f47187.svd
Finished dev [unoptimized + debuginfo] target(s) in 0.16s
Running target\debug\msp430gen.exe msp430f47187
erasing PBIN (keeping P9IN)
erasing PBOUT (keeping P9OUT)
erasing PBDIR (keeping P9DIR)
erasing PBSEL (keeping P9SEL)
erasing PAREN (keeping P7REN)
erasing PBREN (keeping P9REN)
erasing PAIN (keeping P7IN)
erasing PAOUT (keeping P7OUT)
erasing PADIR (keeping P7DIR)
erasing PASEL (keeping P7SEL)
erasing RTCTL (keeping BTCTL)
erasing RTCTIM0 (keeping RTCNT1)
erasing RTCTIM1 (keeping RTCNT3)
erasing BTCNT12 (keeping BTCNT1)
erasing RTCDATE (keeping RTCDAY)
erasing RTCYEAR (keeping RTCYEARL)
warning: register MPY_B (MPY) has missing parts
erasing MPY (keeping MPY_B)
warning: register MPYS_B (MPYS) has missing parts
erasing MPYS (keeping MPYS_B)
warning: register MAC_B (MAC) has missing parts
erasing MAC (keeping MAC_B)
warning: register MACS_B (MACS) has missing parts
erasing MACS (keeping MACS_B)
warning: register OP2_B (OP2) has missing parts
erasing OP2 (keeping OP2_B)
warning: register MPY32L_B (MPY32L) has missing parts
erasing MPY32L (keeping MPY32L_B)
warning: register MPY32H_B (MPY32H) has missing parts
erasing MPY32H (keeping MPY32H_B)
warning: register MPYS32L_B (MPYS32L) has missing parts
erasing MPYS32L (keeping MPYS32L_B)
warning: register MPYS32H_B (MPYS32H) has missing parts
erasing MPYS32H (keeping MPYS32H_B)
warning: register MAC32L_B (MAC32L) has missing parts
erasing MAC32L (keeping MAC32L_B)
warning: register MAC32H_B (MAC32H) has missing parts
erasing MAC32H (keeping MAC32H_B)
warning: register MACS32L_B (MACS32L) has missing parts
erasing MACS32L (keeping MACS32L_B)
warning: register MACS32H_B (MACS32H) has missing parts
erasing MACS32H (keeping MACS32H_B)
warning: register OP2L_B (OP2L) has missing parts
erasing OP2L (keeping OP2L_B)
warning: register OP2H_B (OP2H) has missing parts
erasing OP2H (keeping OP2H_B)
thread 'main' panicked at 'unexpected registers
OLD Register {
name: "DMA0SAL",
description: "DMA Channel 0 Source Address",
module: "DMA",
offset: 466,
width: 2,
fields: [],
alternate: None,
}
NEW Register {
name: "DMA0SA",
description: "DMA Channel 0 Source Address",
module: "DMA",
offset: 466,
width: 4,
fields: [],
alternate: None,
}
Please file an issue at https://github.com/pftbest/msp430_svd/issues', src\dslite_parser.rs:88:17
note: run with RUST_BACKTRACE=1 environment variable to display a backtrace
error: process didn't exit successfully: target\debug\msp430gen.exe msp430f47187 (exit code: 101)

SVDs generated currently a byte-wise size of 2; they need to have a bit-wise size of 16. see also pftbest/msp430g2553#6.

While trying to generate svd files for the MSP430FR2433 target I get a panic due to same offset/width for a register. Here's part of the error:

thread 'main' panicked at 'conflict in the same module
OLD Register {
    name: "UCB0IE",
    description: "USCI B0 Interrupt Enable Register",
    module: "USCI_B0  I2C Mode",
    offset: 1386,
    width: 2,
    fields: []
}
NEW Register {
    name: "UCB0IE__I2C",
    description: "USCI B0 Interrupt Enable Register",
    module: "USCI_B0  I2C Mode",
    offset: 1386,
    width: 2,
    fields: [
            ... etc ....

The current version we have is 1.198 - 22.11.2016

But the version in CCS is 1.203 (10/05/2017)

I am getting this error when trying to generate the svd for the msp430g2553 used in the example. I am new to rust and not sure how to fix this. I would like to run this for the msp430f6736a, but wanted to make sure the examples works...
Any help would be appreciated!

We really should do more than unwrap. And return actual proper error information. I like using eyre, an anyhow variant that can be customized. There are a number of sites where creating an SVD can just plain-out die, and eyre gives me a good way to present this information.

Unfortunately, I lack the energy/will to make this change right now.

If you generate an SVD file using msp430_svd, there are some registers which are missing fields completely (TAIV timer register), and others where fields aren't documented (Watchdog timer password). This can be seen seen in the following run (no fields in register):

William@DESKTOP-H0PMN4M MINGW64 ~/Projects/MSP430/msp430_svd
$ cargo run -- msp430g2211 | xmllint --format - > msp430g2211.svd
warning: use of deprecated item 'try': use the `?` operator instead
  --> src\utils.rs:41:20
   |
41 |     let mut file = try!(File::open(file_name).map_err(|_| format!("can't open {:?}", file_name)));
   |                    ^^^
   |
   = note: `#[warn(deprecated)]` on by default

warning: use of deprecated item 'try': use the `?` operator instead
  --> src\utils.rs:43:5
   |
43 |     try!(
   |     ^^^

warning: use of deprecated item 'try': use the `?` operator instead
  --> src\utils.rs:51:20
   |
51 |     let mut file = try!(File::open(file_name).map_err(|_| format!("can't open {:?}", file_name)));
   |                    ^^^

warning: use of deprecated item 'try': use the `?` operator instead
  --> src\utils.rs:53:5
   |
53 |     try!(
   |     ^^^

    Finished dev [unoptimized + debuginfo] target(s) in 0.17s
     Running `target\debug\msp430gen.exe msp430g2211`
skipping aliased vector TIMER0_A1_VECTOR
skipping aliased vector TIMER0_A0_VECTOR
warning: no fields in register CALDCO_1MHZ
warning: no fields in register CALBC1_1MHZ
warning: no fields in register TAIV
warning: no fields in register TAR
warning: no fields in register TACCR0
warning: no fields in register TACCR1

The end result is that there are no fields generated in the PAC crate for accessing these registers safely at all, even when all bits are valid- only the unsafe bits function. There also appears to be a commented-out code path for introducing a writeConstraint when a register field is lacking enums. This is appropriate for registers like TACCR0 (which has no need for enums), so perhaps we could consider uncommenting this?

I'm not sure how to go about fixing this, but I think perhaps there should be a way to include XML overrides in a separate directory, which then get "merged" with the official DSLite XML files? This allows us to separate our changes from what TI officially provides cleanly.

Btw, @pftbest, any chance you could log back into Freenode IRC or Matrix? I haven't seen you around, and I'd like to touch base on the status of msp430 Rust.