MSP430 support

[japaric]

Parent issue: #2

Next steps:

• rustc: Enable the MSP430 LLVM backend, implement cabi stuff,
  etc. See enable the MSP430 LLVM backend rust-lang/rust#37672
• Experiment with a custom target out of tree. Please document everything you do! You don't have to write a tutorial but take note of all the tools you use, the environment you used, the steps you did. Bonus points if you write down the outputs of running readelf -h and objdump -Cd on your (working) programs. LED blinking example
• rustc: fix the LLVM assertion reported in LLVM assertion when compiling core for the MSP430 architecture rust-lang/rust#37829. It block us from compiling the core crate
• rustc: unrecognized character `@' in symbol names. [MSP430] Do not generate '@' character in symbol names. rust-lang/rust#38286. It's also blocking us from compiling core.
• rustc: add a "msp430-interrupt" ABI to support interrupts as extern "msp430-interrupt" fn. (Done in calling convention for MSP430 interrupts rust-lang/rust#38465)
• rustc: support the __bic_SR_register_on_exit gcc built-in somehow. Needed to enter/leave low-power mode.
• Write documentation about writing/compiling/flashing/debugging Rust
  programs for this target. (See https://github.com/pftbest/rust_on_msp)
• Add a built-in MSP430 target to rustc
• 🎉

[japaric]

Experiment with a custom target out of tree

rust-lang/rust#37672 has a custom target specification in the PR description but
it has only been lightly tested. What needs to be done after that PR lands is
compiling a Rust program that actually "works", i.e. that can be flashed and
that boots correctly.

To do that, we need to know low level details about the microcontrollers:

• How does the boot process work?
• How is the memory address space organized? What addresses belong to RAM, which
  ones belong to Flash? etc.

And about the tooling, in particular linker scripts.

msp430-gcc ships with several linker scripts. Using the linker scripts
(memory.x and periph.x) of the msp430g2202 micro and an empty file I get
this:

$ touch empty.c

$ clang --target=msp430 empty.c

$ msp430-objdump -Cd a.out
0000f800 <__watchdog_support>:
    f800:       55 42 20 01     mov.b   &0x0120,r5
    f804:       35 d0 08 5a     bis     #23048, r5      ;#0x5a08
    f808:       82 45 00 02     mov     r5,     &0x0200

0000f80c <__init_stack>:
    f80c:       31 40 00 03     mov     #768,   r1      ;#0x0300

0000f810 <__do_copy_data>:
    f810:       3f 40 00 00     mov     #0,     r15     ;#0x0000
    f814:       0f 93           tst     r15
    f816:       08 24           jz      $+18            ;abs 0xf828
    f818:       92 42 00 02     mov     &0x0200,&0x0120
    f81c:       20 01
    f81e:       2f 83           decd    r15
    f820:       9f 4f 4a f8     mov     -1974(r15),512(r15);0xf84a(r15), 0x0200(r15)
    f824:       00 02
    f826:       f8 23           jnz     $-14            ;abs 0xf818

0000f828 <__do_clear_bss>:
    f828:       3f 40 00 00     mov     #0,     r15     ;#0x0000
    f82c:       0f 93           tst     r15
    f82e:       07 24           jz      $+16            ;abs 0xf83e
    f830:       92 42 00 02     mov     &0x0200,&0x0120
    f834:       20 01
    f836:       1f 83           dec     r15
    f838:       cf 43 00 02     mov.b   #0,     512(r15);r3 As==00, 0x0200(r15)
    f83c:       f9 23           jnz     $-12            ;abs 0xf830

0000f83e <__stop_progExec__>:
    f83e:       32 d0 f0 00     bis     #240,   r2      ;#0x00f0
    f842:       fd 3f           jmp     $-4             ;abs 0xf83e

0000f844 <__ctors_end>:
    f844:       30 40 48 f8     br      #0xf848

0000f848 <_unexpected_>:
    f848:       00 13           reti

Disassembly of section .vectors:

0000ffe0 <__ivtbl_16>:
    ffe0:       44 f8 44 f8 44 f8 44 f8 44 f8 44 f8 44 f8 44 f8     D.D.D.D.D.D.D.D.
    fff0:       44 f8 44 f8 44 f8 44 f8 44 f8 44 f8 44 f8 00 f8     D.D.D.D.D.D.D...

I expect this program should "work" if flashed into the micro. As least it
should boot properly.

Changing the C source code to:

int main() {
    while (1) {}
}

Changes the disassembly like this:

     f818:      92 42 00 02     mov     &0x0200,&0x0120
     f81c:      20 01
     f81e:      2f 83           decd    r15
-    f820:      9f 4f 4a f8     mov     -1974(r15),512(r15);0xf84a(r15), 0x0200(r15)
+    f820:      9f 4f 5a f8     mov     -1958(r15),512(r15);0xf85a(r15), 0x0200(r15)
     f824:      00 02
     f826:      f8 23           jnz     $-14            ;abs 0xf818

@@ -38,10 +38,19 @@
     f842:      fd 3f           jmp     $-4             ;abs 0xf83e

 0000f844 <__ctors_end>:
-    f844:      30 40 48 f8     br      #0xf848
+    f844:      30 40 58 f8     br      #0xf858

-0000f848 <_unexpected_>:
-    f848:      00 13           reti
+0000f848 <main>:
+    f848:      04 12           push    r4
+    f84a:      04 41           mov     r1,     r4
+    f84c:      21 83           decd    r1
+    f84e:      84 43 fe ff     mov     #0,     -2(r4)  ;r3 As==00, 0xfffe(r4)
+    f852:      00 3c           jmp     $+2             ;abs 0xf854
+    f854:      ff 3f           jmp     $+0             ;abs 0xf854
+       ...
+
+0000f858 <_unexpected_>:
+    f858:      00 13           reti

 Disassembly of section .vectors:

But compiling the following Rust program:

#![feature(lang_items)]
#![feature(no_core)]
#![no_core]
#![no_main]

#[export_name = "main"]
pub fn main() -> ! {
    loop {}
}

#[lang = "copy"]
trait Copy {}

#[lang = "sized"]
trait Sized {}

produces the same disassembly as the empty C source file. This means that the
linker is dropping all the Rust symbols. Have to figure out why that's the case.

[pftbest]

I can get a MSP430 board tomorrow, to do some tests.
Also I have a question, how does rust support __attribute__((interrupt)) declaration?
And there is no way (as far as I know) to exit low-power mode, because __bic_SR_register_on_exit built-in is not implemented in llvm.

[japaric]

how does rust support attribute((interrupt)) declaration?

It doesn't right now. We'll have to add a new ABI, e.g. extern "msp430-interrupt", to get the ABI/prelude/calling convention right. The AVR folks have done something like this, I think.

[japaric]

because __bic_SR_register_on_exit built-in is not implemented in llvm.

Could you elaborate about what this does? Is a gcc intrinsic built-in (?) that lowers to an assembly instruction? Or something else?

[pftbest]

@japaric

Could you elaborate about what this does?

It modifies the value on the stack that is located one word below the current frame (I don't know the right words how to say this). Basically when CPU enters interrupt it does this:

1. CPU pushes status register on stack
2. CPU jumps to interrupt handler
3. interrupt handler pushes some stuff on the stack (it's frame)
4. here we need to modify the value that was pushed on stack by CPU on step 1 but we can't locate it because only compiler knows how much stuff we have pushed on step 3, that's why we use built-in.
5. interrupt handler pops it's frame from the stack and calls reti
6. CPU pops the value from stack and writes it to status register.

As far as I know this is the only way to modify the status register and exit low power mode.

[pftbest]

@japaric
Maybe it is possible to implement this behaviour using naked functions and some assembly code, but I have not tried.

[japaric]

The built-in looks like a function call that goes inside an "interrupt handler"? Something like this:

__irq void foo() {
    // ..

     __bic_SR_register_on_exit();
}

Maybe it is possible to implement this behaviour using naked functions and some assembly code, but I have not tried.

Maybe. But I think that if you use a naked function then you have to manually modify the stack pointer during the prologue/epilogue of the function according to the number of local variables you use. My worry is that this approach may require the (final) user to deal with low level ABI-ish details.

[japaric]

The built-in looks like a function call that goes inside an "interrupt handler"?

Or is an attribute?

[pftbest]

The built-in looks like a function call that goes inside an "interrupt handler"?

Yes, it looks and feels like normal function.

Synopsis

unsigned __bic_SR_register_on_exit(unsigned mask);

Description

__bic_SR_register_on_exit clears the bits specified in mask in the saved status register of an interrupt function (i.e. it bitwise ands the complement of mask into the saved status register). This allows you to change the operating mode of the MSP430 on return from the interrupt service routine, such as changing the low power mode.
__bic_SR_register_on_exit returns the value of the saved MSP430 status register before the update.
__bic_SR_register_on_exit is an intrinsic function and produces inline code.

Note

__bic_SR_register_on_exit can only be used in interrupt functions—an error is reported if it is used outside an interrupt function.

[pftbest]

I think it is not possible to write llvm IR that will do this kind of thing. So this function should be added as intrinsic in llvm (and as built-in in clang). and only then we can have it in rust.

[japaric]

rust-lang/rust#37672 has landed and the MSP430 LLVM backend should be enabled in the next nightly. People should be able to experiment with custom targets out of tree with that nightly.

[jck]

I've got a couple of MSP430 fram boards. I'll try out a blinky tomorrow.

On Tue, Nov 15, 2016, 23:06 Jorge Aparicio notifications@github.com wrote:

rust-lang/rust#37672 rust-lang/rust#37672 has
landed and the MSP430 LLVM backend should be enabled in the next nightly.
People should be able to experiment with custom targets out of tree with
that nightly.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
#20 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AATR7uoRMeferu2kSHoryoaAybZB9qLOks5q-oFcgaJpZM4KvzaQ
.