msp430x port

[Giovanni]

It is called USART0TX_VECTOR in mspgcc too, vectUSART0TX is a string built for the ISR function name in chcore.h.

Probably it is the compiler version number 4.5.3 vs 4.6.3, not just the headers. I think it will be fine once Ubuntu repos are updated with the latest version.

Does mspgcc have Linux binaries or the only option is to build it?

[erwinkendo]

Hello

Well, I just compiled the last trunk version, and it compiled perfectly.

I am using the last mspgcc in my Archlinux machine. I have instaled not only binutils and the gcc compiler, but the standar libs and mcu package that provides the linker scripts and the .h for specific arquitectures and general msp430 devices, for my archlinux arquitecture would be this packages [1] and for ubuntu this ones [2]

This mspgcc [3] is described as follows:

This wiki describes the current maintained version of gcc, which evolved under the name Uniarch. The original mspgcc3-based version of this wiki and original project home page are still available for reference. Interested parties can read the history of mspgcc.

. In that you can see the compiling instructions and the standar packages.

I will try and test the code for a different MCU and test it latter this night.

[1] http://aur.archlinux.org/packages.php?O=0&K=msp430&do_Search=Ir
[2] https://launchpad.net/ubuntu/oneiric/+search?text=msp430
[3] http://sourceforge.net/apps/mediawiki/mspgcc/index.php?title=MSPGCC_Wiki

[hal]

I have been porting ChibiOS to msp430x (msp430f5437). The port seems to be complete so far, but running TestThread doesn't confirm this:

*** Kernel: 2.4.2
*** Compiled: Nov 2 2012 - 15:30:01
*** Compiler: IAR IAR C/C++ Compiler V5.10.1.50144/W32 for MSP430
*** Architecture: MSP430
*** Core Variant: MSP430X
*** Port Info: None
*** Platform: MSP430X
*** Test Board: NONSTANDARD MSP430-F5437

----------------------------------------------------------------------------
--- Test Case 1.1 (Threads, enqueuing test #1)
--- Result: FAILURE (#1 [>t]) <<<<<=================================!!!

Short preamble: In this test one buffer will be written by 5 threads, each of these has as arg a pointer to a char e.g. "E", "D" .. "A", afterwards the buffer will be compared with "ABCDE" pattern - with SUCCESS on equality. The test is failed so i was trying to understand the reason.

Each thread function testhd.c:thread(void *p) is called from chcore.c:_port_thread_start()
void _port_thread_start(void) {
chSysUnlock();
asm("mova r11, r15"); // what does this do - the arg will be passed to a thread? why is r15 being used at all?
asm("calla r10"); // call thread function, which expects an arg in r12, r12 is not set by now?!..
asm("calla #chThdExit");
}

As seen from above the thread function will be called from asm("calla r10") and receive a incorrect pointer p! The correct pointer to character is in r11 (as seen in debugger) an will be uselessly copied to r15? I don't really understand how it works. Can anyone help?

----------------------------------------------------------------------------
--- Test Case 1.2 (Threads, enqueuing test #2)
--- Result: FAILURE (#1 [>t])
----------------------------------------------------------------------------
--- Test Case 1.3 (Threads, priority change)
--- Result: SUCCESS
----------------------------------------------------------------------------
--- Test Case 1.4 (Threads, delays)
--- Result: SUCCESS
----------------------------------------------------------------------------
--- Test Case 2.1 (Semaphores, enqueuing)
--- Result: FAILURE (#1 [ÒœÐ])
----------------------------------------------------------------------------
--- Test Case 2.2 (Semaphores, timeout)
--- Result: SUCCESS
----------------------------------------------------------------------------
--- Test Case 2.3 (Semaphores, atomic signal-wait)
--- Result: SUCCESS
----------------------------------------------------------------------------
--- Test Case 2.4 (Binary Semaphores, functionality)

[Giovanni]

Hi,

Those registers are for MSPGCC, you ported to IAR so you have to use the right registers for that architecture for parameter passing. I also recommend that you verify if the structures intctx and extctx are right for the IAR compiler.

In general intctx contains the registers that are preserved by functions, extctx contains the registers saved by ISRs.

Giovanni

[hal]

Hi Giovanni,

thank you for answer, it did help - see report below. mspgcc and IAR ABI are different. The main modification was changing from asm("mova r11, r15") to asm("mova r11, r12") to get IAR happy, added some other compiler specifics and it ran. I was able to compile the port with the mspgcc too. Are you interested in a patch?



ChibiOS/RT Shell
ch> help
Commands: help exit info systime mem threads test reboot
ch> mem
core free memory : 16382 bytes
heap fragments : 0
heap free total : 0 bytes
ch> threads
addr stack prio refs state time
00001E08 00005BA6 64 1 SLEEPING 0
00001D6E 00001DBC 1 1 READY 5577
00001E52 00001F6A 64 1 CURRENT 9
ch> test

*** ChibiOS/RT test suite
***
*** Kernel: 2.4.2
*** Compiled: Nov 6 2012 - 14:38:36
*** Compiler: IAR IAR C/C++ Compiler V5.10.1.50144/W32 for MSP430
*** Architecture: MSP430
*** Core Variant: MSP430X
*** Port Info: None
*** Platform: MSP430X
*** Test Board: NONSTANDARD MSP430-F5437

----------------------------------------------------------------------------
--- Test Case 1.1 (Threads, enqueuing test #1)
--- Result: SUCCESS
----------------------------------------------------------------------------
--- Test Case 1.2 (Threads, enqueuing test #2)
--- Result: SUCCESS
----------------------------------------------------------------------------
--- Test Case 1.3 (Threads, priority change)
--- Result: SUCCESS
----------------------------------------------------------------------------
--- Test Case 1.4 (Threads, delays)
--- Result: SUCCESS
----------------------------------------------------------------------------
--- Test Case 2.1 (Semaphores, enqueuing)
--- Result: SUCCESS
----------------------------------------------------------------------------
--- Test Case 2.2 (Semaphores, timeout)
--- Result: SUCCESS
----------------------------------------------------------------------------
--- Test Case 2.3 (Semaphores, atomic signal-wait)
--- Result: SUCCESS
----------------------------------------------------------------------------
--- Test Case 2.4 (Binary Semaphores, functionality)
--- Result: SUCCESS
----------------------------------------------------------------------------
--- Test Case 3.1 (Mutexes, priority enqueuing test)
--- Result: SUCCESS
----------------------------------------------------------------------------
--- Test Case 3.2 (Mutexes, priority inheritance, simple case)
--- Result: SUCCESS
----------------------------------------------------------------------------
--- Test Case 3.3 (Mutexes, priority inheritance, complex case)
--- Result: SUCCESS
----------------------------------------------------------------------------
--- Test Case 3.4 (Mutexes, priority return)
--- Result: SUCCESS
----------------------------------------------------------------------------
--- Test Case 3.5 (Mutexes, status)
--- Result: SUCCESS
----------------------------------------------------------------------------
--- Test Case 3.6 (CondVar, signal test)
--- Result: SUCCESS
----------------------------------------------------------------------------
--- Test Case 3.7 (CondVar, broadcast test)
--- Result: SUCCESS
----------------------------------------------------------------------------
--- Test Case 3.8 (CondVar, boost test)
--- Result: SUCCESS
----------------------------------------------------------------------------
--- Test Case 4.1 (Messages, loop)
--- Result: SUCCESS
----------------------------------------------------------------------------
--- Test Case 5.1 (Mailboxes, queuing and timeouts)
--- Result: SUCCESS
----------------------------------------------------------------------------
--- Test Case 6.1 (Events, registration and dispatch)
--- Result: SUCCESS
----------------------------------------------------------------------------
--- Test Case 6.2 (Events, wait and broadcast)
--- Result: SUCCESS
----------------------------------------------------------------------------
--- Test Case 6.3 (Events, timeouts)
--- Result: SUCCESS
----------------------------------------------------------------------------
--- Test Case 7.1 (Heap, allocation and fragmentation test)
--- Result: SUCCESS
----------------------------------------------------------------------------
--- Test Case 8.1 (Memory Pools, queue/dequeue)
--- Result: SUCCESS
----------------------------------------------------------------------------
--- Test Case 9.1 (Dynamic APIs, threads creation from heap)
--- Result: SUCCESS
----------------------------------------------------------------------------
--- Test Case 9.2 (Dynamic APIs, threads creation from memory pool)
--- Result: SUCCESS
----------------------------------------------------------------------------
--- Test Case 9.3 (Dynamic APIs, registry and references)
--- Result: SUCCESS
----------------------------------------------------------------------------
--- Test Case 10.1 (Queues, input queues)
--- Result: SUCCESS
----------------------------------------------------------------------------
--- Test Case 10.2 (Queues, output queues)
--- Result: SUCCESS
----------------------------------------------------------------------------
--- Test Case 11.1 (Benchmark, messages #1)
--- Score : 35776 msgs/S, 71552 ctxswc/S
--- Result: SUCCESS
----------------------------------------------------------------------------
--- Test Case 11.2 (Benchmark, messages #2)
--- Score : 29058 msgs/S, 58116 ctxswc/S
--- Result: SUCCESS
----------------------------------------------------------------------------
--- Test Case 11.3 (Benchmark, messages #3)
--- Score : 29058 msgs/S, 58116 ctxswc/S
--- Result: SUCCESS
----------------------------------------------------------------------------
--- Test Case 11.4 (Benchmark, context switch)
--- Score : 121080 ctxswc/S
--- Result: SUCCESS
----------------------------------------------------------------------------
--- Test Case 11.5 (Benchmark, threads, full cycle)
--- Score : 19687 threads/S
--- Result: SUCCESS
----------------------------------------------------------------------------
--- Test Case 11.6 (Benchmark, threads, create only)
--- Score : 28848 threads/S
--- Result: SUCCESS
----------------------------------------------------------------------------
--- Test Case 11.7 (Benchmark, mass reschedule, 5 threads)
--- Score : 8613 reschedules/S, 51678 ctxswc/S
--- Result: SUCCESS
----------------------------------------------------------------------------
--- Test Case 11.8 (Benchmark, round robin context switching)
--- Score : 79452 ctxswc/S
--- Result: SUCCESS
----------------------------------------------------------------------------
--- Test Case 11.9 (Benchmark, I/O Queues throughput)
--- Score : 113428 bytes/S
--- Result: SUCCESS
----------------------------------------------------------------------------
--- Test Case 11.10 (Benchmark, virtual timers set/reset)
--- Score : 107908 timers/S
--- Result: SUCCESS
----------------------------------------------------------------------------
--- Test Case 11.11 (Benchmark, semaphores wait/signal)
--- Score : 138636 wait+signal/S
--- Result: SUCCESS
----------------------------------------------------------------------------
--- Test Case 11.12 (Benchmark, mutexes lock/unlock)
--- Score : 105072 lock+unlock/S
--- Result: SUCCESS
----------------------------------------------------------------------------
--- Test Case 11.13 (Benchmark, RAM footprint)
--- System: 348 bytes
--- Thread: 62 bytes
--- Timer : 18 bytes
--- Semaph: 10 bytes
--- EventS: 4 bytes
--- EventL: 10 bytes
--- Mutex : 16 bytes
--- CondV.: 8 bytes
--- Queue : 32 bytes
--- MailB.: 36 bytes
--- Result: SUCCESS
----------------------------------------------------------------------------

Final result: SUCCESS

[Giovanni]

Hi,

Good work, sure, submit it.

Giovanni

[Giovanni]

Hi,

I am merging the patch you posted in the tracker, is the new common/MSP430x supposed to replace the old GCC/MSP430 ?

Also, I removed the proprietary libs from the HAL, you should include them in your application not in the distribution code.

Giovanni

[hal]

Hi Giovanni,

common/msp430x is not supposed to replace the old GCC/msp430. msp430x port is relying on extended cpu instruction set: calla, mova and so on. The code would possibly become very rich in #ifdef constructions on trying to merge both ports together.

I've totally overseen TI libs in the HAL directory, sorry. I mean, that these libs have been used only from within application, so you can delete them from HAL or move them to application dir.

[saraben]

Hal, Giovanni,
Has any one had issues with the port_switch for the MSP430? I didn't find any forum comments.
I compiled with mspgcc 4.6.3, and it produced disassembled code that looks like this:

Code: Select all

 233           chSysSwitch(ntp, otp);
0000c5bc:   mov\t@r1,\tr14\t 
0000c5be:   mov\t4(r1),\tr15\t;0x0004(r1) 
0000c5c2:   call\t#0xc07e\t 
 
          port_switch:
0000c07e:   mov\tr15,\t0(r1)\t;0x0000(r1) 
0000c082:   mov\tr14,\t2(r1)\t;0x0002(r1) 
  49         asm volatile ("push    r11                                    \n\t" \
0000c086:   push\tr11\t\t [255]
0000c088:   push\tr10\t\t [255]
0000c08a:   push\tr9\t\t [255]
0000c08c:   push\tr8\t\t [0]
0000c08e:   push\tr7\t\t [0]
0000c090:   push\tr6\t\t [0]
0000c092:   push\tr5\t\t [23048]
0000c094:   push\tr4\t\t [0]
 57         otp->p_ctx.sp = sp;
0000c096:   mov\tr1,\tr14\t 
0000c098:   mov\t2(r1),\tr15\t;0x0002(r1) 
0000c09c:   mov\tr14,\t6(r15)\t;0x0006(r15) 
 58         sp = ntp->p_ctx.sp;
0000c0a0:   mov\t@r1,\tr15\t 
0000c0a2:   mov\t6(r15),\tr15\t;0x0006(r15) 
0000c0a6:   mov\tr15,\tr1\t 
 59         asm volatile ("pop     r4                                     \n\t" \
0000c0a8:   mov\tr1,\tr15\t 
0000c0aa:   pop\tr4\t\t 
0000c0ac:   pop\tr5\t\t 
0000c0ae:   pop\tr6\t\t 
0000c0b0:   pop\tr7\t\t 
0000c0b2:   pop\tr8\t\t 
0000c0b4:   pop\tr9\t\t 
0000c0b6:   pop\tr10\t\t 
0000c0b8:   pop\tr11\t\t 
0000c0ba:   ret\t\t\t 

The problem is that it basically stores the two thread pointers in r15 and r14, then on the stack at lines C07E to C082.
On lines C0A0 to C0A2 the compiled C code uses the R5 which has been pushed onto the stack, at c092, as the pointer for otp, but this value is just garbage, and clobbered the valid pointers.
Likewise for ntp in lines C0A0 to C0A6.
Obvious the program goes off into the never-never.
This morning I just used assembly to fix the issue replacing the two lines of C.

Code: Select all

  asm volatile ("mov r1,6(r14)");
  asm volatile ("mov 6(r15),r1");

Alternative they could be read from the stack.

Code: Select all

  asm volatile ("mov r1,16(r1)");
  asm volatile ("mov 18(r1),r1");

This evening I looked at Hal's new code and in the IAR version it is similar to the modified version, except the structure of Thread must be different as as the Thread pointer to SP offset is 10 not 6.
The GCC version is as per the previous repo. code, with the C statements between the assembler.
I will have a go at compiling with 4.7 but I have had some reliability problems with that which is why I am using the "stable" version.

Regards saraben.

[Giovanni]

Hi, I have to verify this, the old mspgcc didn't generate that mess.

Giovanni