Jump to content
dubnet

Wolverine Launchpad

Recommended Posts

Thanks for clarifying that.

 

edit: So in theory the table could be correctly used in msp430mcu-20130321 by adjusting the vector addresses at the end of (e.g.) msp430fr5969.h to add the additional offset?

 

Assuming we're still talking about this error:

 Linking main.elf
~/energia-0101E0010/hardware/tools/msp430/bin/msp430-gcc  -mmcu=msp430fr5969 -Wl,-Map=main.map   main.o .lib/lib.a -o main.elf
main.o:(.vectors+0x0): multiple definition of `__ivtbl_64'
~/energia-0101E0010/hardware/tools/msp430/bin/../lib/gcc/msp430/4.6.3/mcpu-430x/mmpy-16/crt0ivtbl64.o:(.vectors+0x0): first defined here
~/energia-0101E0010/hardware/tools/msp430/bin/../lib/gcc/msp430/4.6.3/../../../../msp430/bin/ld: main.elf section `.vectors' will not fit in region `vectors'
~energia-0101E0010/hardware/tools/msp430/bin/../lib/gcc/msp430/4.6.3/../../../../msp430/bin/ld: region `vectors' overflowed by 128 bytes
collect2: ld returned 1 exit status
make: *** [main.elf] Errore 1

 

then in theory it's fixed by figuring out who's putting two definitions of __ivtbl_64 into that link line. Normally it should be coming from crt0ivtbl64.o, which mspgcc adds, so presumably there's another in .lib/lib.a (or, somehow, main.o).  There should be no reason to touch linker scripts; the interrupt issue is not relevant unless you're using one of the affected versions of msp430mcu (none of which were ever approved for use with an LTS or development version of mspgcc; if energia updated to one of those, it probably wouldn't work at all).

 

I'll be getting my EXP430FR5969-LP probably today, so will be able to check things out soon (though I normally use an internal development version of mspgcc so my results may not apply).

Share this post


Link to post
Share on other sites

 

I'll be getting my EXP430FR5969-LP probably today, so will be able to check things out soon (though I normally use an internal development version of mspgcc so my results may not apply).

 

Thanks!

 

I'm not an expert in Makefiles so I've probably done a lot of mistakes (I've posted a link to the makefile I'm using in a previous message: http://forum.43oh.com/topic/5011-wolverine-launchpad/page-2#entry44970  ).

 

I'm only using free (as in speech) software so if I can't use mspgcc I feel I have no other options.

 

Please let me know if yout tests are successfull.

 

Here is the memory map, if anybody can read this http://dpaste.com/hold/1662533/ 

Share this post


Link to post
Share on other sites

I'm not an expert in Makefiles so I've probably done a lot of mistakes (I've posted a link to the makefile I'm using in a previous message: http://forum.43oh.com/topic/5011-wolverine-launchpad/page-2#entry44970  ).

 

I did a total slash and burn of slac645 and tracked down the problem: two incompatible rules to build object files, one of which actually built an executable. I have no idea whether it would run; I won't be trying out this board until later this week.

 

Diffs for a Makefile that fixes the link issue are at: https://gist.github.com/pabigot/9235449/revisions

 

Some of the changes are irrelevant; you probably only need the one that comments out the %o rule.

 

Good luck.

Share this post


Link to post
Share on other sites

It works!

 

The people on this forum is great!

 

Thank you all!

 

So far: I've compiled and loaded the example in MSP-EXP430FR5969/Software/430BOOST-SHARP96_GrlibDisplay

 

This is what I've changed:

touch grlib/assert.h 
echo "#define assert(x)" > grlib/assert.h 

then I had to rewrite an asm function, the __reverse  did not work (help needed) but the first works:

cat LcdDriver/Sharp96x96utils.h 
/* --COPYRIGHT--,BSD
 * Copyright (c) 2013, Texas Instruments Incorporated
 * All rights reserved.

[.....]

 * --/COPYRIGHT--*/

 //*****************************************************************************
//
// Sharp400x240utils.h
//
//
//*****************************************************************************

#ifndef SHARP96X96UTILS_H_
#define SHARP96X96UTILS_H_


unsigned char reverse(unsigned char 
{
  unsigned char tmp = 0;
  unsigned char i=0;

  for( i=0; i<8; i++ )
  {
    __asm__ (
        " rrc.b  %[b] \n"
        " rlc.b  %[tmp] \n"
        : [tmp] "+r"(tmp)
        : [b] "r"();
  }
    return tmp;
}

// THIS DOES NOT WORK (endless loop)
unsigned char __reverse(unsigned char x) {
__asm__ (
        "    mov.b   R12, R13           \n"
        "    rlc.b   R13                \n"
        "    rrc.b   R12                \n"
        "    rlc.b   R13                \n"
        "    rrc.b   R12                \n"
        "    rlc.b   R13                \n"
        "    rrc.b   R12                \n"
        "    rlc.b   R13                \n"
        "    rrc.b   R12                \n"
        "    rlc.b   R13                \n"
        "    rrc.b   R12                \n"
        "    rlc.b   R13                \n"
        "    rrc.b   R12                \n"
        "    rlc.b   R13                \n"
        "    rrc.b   R12                \n"
        "    rlc.b   R13                \n"
        "    rrc.b   R12                \n"
        "    reta                       \n"
        :                                 // no output
        : [x] "r" (x) // input
        :                                 // no memory clobber
    
);
}

#endif /* SHARP96X96UTILS_H_ */

Using the makefile corrected by @@pabigot everything works.

 

I was also able to debug with gdb to find out the reverse problem.

 

 

 

 

 

 

 

Share this post


Link to post
Share on other sites

Here's your reverse function:

static unsigned char
reverse (unsigned char i)
{
  unsigned char rv;
  __asm__ __volatile__ ("rlc.b\t%1\n"
                        "\trrc.b\t%0\n"
                        "\trlc.b\t%1\n"
                        "\trrc.b\t%0\n"
                        "\trlc.b\t%1\n"
                        "\trrc.b\t%0\n"
                        "\trlc.b\t%1\n"
                        "\trrc.b\t%0\n"
                        "\trlc.b\t%1\n"
                        "\trrc.b\t%0\n"
                        "\trlc.b\t%1\n"
                        "\trrc.b\t%0\n"
                        "\trlc.b\t%1\n"
                        "\trrc.b\t%0\n"
                        "\trlc.b\t%1\n"
                        "\trrc.b\t%0\n"
                        : "=&r" (rv) /* Output must be register, is write-only and clobbered */
                          , "+r"(i)  /* Input is register and is mutated */
                        : );
  return rv;
}

The main problem with your original is that MSPGCC ABI requires that the input argument is passed in R15, and the output is returned in R15.

See the gcc constraint modifier documentation.

Edited by pabigot

Share this post


Link to post
Share on other sites

Not sure yet whether to splurge for one of these or not. Am I correct that with the LCD boosterpack attached, you don't have access to any of the pins of the launchpad? Or does it have female sockets underneath like the stellaris LP's?

Share this post


Link to post
Share on other sites

Would anyone like to do a review post on the Wolverine LP for the 43oh Blog? You get bonus karma points and a link to your Blog( if you have one ). Post should have a good amount of pictures( good quality ) and a writeup. If you want a PCB from the 43oh store, I can do that too.

Share this post


Link to post
Share on other sites

Would anyone like to do a review post on the Wolverine LP for the 43oh Blog?

I wish I could, but I've just not got the time at the moment. All I've managed to do so far was power it from USB and look at the pre-installed sample code.

Share this post


Link to post
Share on other sites

Would anyone like to do a review post on the Wolverine LP for the 43oh Blog? You get bonus karma points and a link to your Blog( if you have one ). Post should have a good amount of pictures( good quality ) and a writeup. If you want a PCB from the 43oh store, I can do that too.

 

I got this toy supported under BSP430 today.  I don't do pictures, and it's slapdash writeup short on detail, but I wrote up some notes on my blog, for those who are interested.  The short version is it works, I now understand why it uses the 20-pin interface (there aren't enough pins to warrant adding the other 20), and it still has a long way to go before it's no longer experimental.

Share this post


Link to post
Share on other sites

How long was it taking to flash that object with the ezfet after the firmware upgade?  I am curious how the updated ezfet compares with the FET430UIF.

 

The update replaces the ezfet interface with the same tilib interface used by the FET430UIF, so I don't use the ezfet driver at all anymore.  tilib through the USB interface runs at the same speed as tilib through the FET430UIF.

Share this post


Link to post
Share on other sites

I've been using mine with the ezfet driver and was hoping there was a way to speed up the interface. The fw-update worked thanks.

I remember reading to run over 8Mhz you have to explicitly define the fram wait state cycles?

I can take some photos for the blog.

Edit: photos.

 

post-274-0-91385300-1393748194_thumb.jpg post-274-0-93979200-1393748278_thumb.jpg

post-274-0-23643700-1393748339_thumb.jpg post-274-0-42561200-1393748381_thumb.jpg

post-274-0-36005000-1393748436_thumb.jpg post-274-0-35145500-1393748480_thumb.jpg

Share this post


Link to post
Share on other sites

Fwiw, I was screwing around with my Wolverine tonight (that sounds dirty) and playing with the wait-states.

 

At 8MHz, 0 wait states works fine as expected.

At 16MHz, 0 wait states bombs.

At 16MHz, 1 wait state works fine.

At 24MHz .... 2 wait states works fine, but so does 1 wait state!  0 wait states bombs.

At 24MHz with DIVM__2 (12MHz MCLK), 0 wait states works.

 

So the actual FRAM speed is probably somewhere in the 12-16MHz range, but they state "125ns" (8MHz) in the datasheet to provide a lot of margin I guess (accounting for DCO drift).  Well either that, or my code is using the FRAM cache efficiently enough that its actual FRAM access is happening at 8MHz or less.  (Probably this...)

 

Testbed is Wolverine LaunchPad w/ Nokia 1202 LCD display and my msp1202 C program compiled with mspgcc 4.6.3 (now with enhanced msp430_spi.c supporting 9-bit SPI on the Wolverine, one more platform to support on top of the other F5xxx and G2xxx's)

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

×