Re: msp430-gcc 4.7 bug with shifts?

Alright sorry about that don't be angry. I will make it work myself. Thanks
for your help

Regard's


On Thu, Jul 11, 2013 at 2:08 AM, Peter Bigot <[email protected]> wrote:

> Once more: this is not an mspgcc problem (or a TinyProd problem), and
> certainly has nothing to do with the shift bug in the subject.
>
> Please don't post to mspgcc-users again about this.  (I don't have any Z1
> hardware, and don't use ARM as a Contiki development platform, so I can't
> help either.)
>
> You need to get support from Contiki or Zolertia or give up on doing
> Contiki development for Z1 hardware on an ARM platform.
>
> Peter
>
>
> On Wed, Jul 10, 2013 at 3:51 PM, Jhon James <[email protected]> wrote:
>
>> Hello Peter
>>
>> Thanks for the pointer. Actually I put the same question on the contiki
>> and tinyOS forum but people suggested me to ask on msp430 mailing list on
>> how to do the porting on the ARM. I followed this page  (
>> http://wiki.contiki-os.org/doku.php?id=msp430x) installed msp430 4.7.0
>> on a PC. Now i am having a problem code gets compiled easily and gets
>> uploaded as well but the problem is with the the make login command when i
>> try to connect to the sensor mote it gets connected but i see garabage of
>> the serial console.
>>
>> The Zolertia team has suggested using the TinyProd from the TinyOS writer
>> but the this works fine but it is precompiled for PC only. you can see this
>> link (
>> http://zolertia.sourceforge.net/wiki/index.php/Mainpage:Contiki_installation_Ubuntu
>> )
>>
>> I installed the version 4.6.3 msp430-gcc using this  command
>>
>> apt-get install binutils-msp430 gcc-msp430 msp430-libc msp430mcu mspdebug ant openjdk-7-jdk
>>
>>
>>  but this version has the same behaviour of loading and compiling code
>> sucessfully while make login command returns the garbage on the console. i
>> think I am close now need some suggestion.
>>
>> I really appreciate your help
>>
>> Regard's
>>
>>
>>
>>
>>
>> On Wed, Jul 10, 2013 at 6:40 AM, Peter Bigot <[email protected]> wrote:
>>
>>> mspgcc does not program images onto MSP430s, so updating to 4.7.0 would
>>> not fix the problem.
>>>
>>> mspdebug is the tool I use for installing images, but Contiki has
>>> traditionally used the BSL facility over a serial line.  If "make TARGET=z1
>>> hello-world.upload" does not result in the board being programmed you
>>> should contact Zolertia for support.  It may be as simple as updating the
>>> udev rules to recognize the board, and is in any case likely to be a Linux
>>> issue rather than an ARM issue.  You could first test basic serial
>>> functionality by taking a board programmed on the PC that does serial
>>> output and making sure you can plug it into the ARM board and receive that
>>> output.
>>>
>>> Questions of this nature really belong on a Zolertia or Contiki support
>>> forum, though.
>>>
>>> Peter
>>>
>>>
>>>
>>> On Tue, Jul 9, 2013 at 8:28 PM, Jhon James <[email protected]> wrote:
>>>
>>>> Hello Peter,
>>>>
>>>> I have previously used the Contiki with Z1 motes on a PC. I used
>>>> msp430-gcc and everything worked quite well. I have now an embedded ARM
>>>> board on which I am trying to install the msp430-gcc compiler. The board
>>>> comes with Ubuntu installed it it. I tried installed msp430-gcc 4.63 on it
>>>> but it did not worked for me since motes cannot be programmed using it. It
>>>> is reommended to use msp430-gcc 4.7.0 I tried but did not suceeded can you
>>>> share some to follow or packages to install. Since you are using contiki
>>>>
>>>> I appreciate your pointers
>>>>
>>>> Thanks
>>>>
>>>>
>>>> On Thu, Jul 4, 2013 at 8:13 PM, Peter Bigot <[email protected]> wrote:
>>>>
>>>>> I'm still analyzing Contiki's mac/rdc/radio layers, and won't be
>>>>> looking at
>>>>> CoAP for a while.  But I see generally what's going on there; it's
>>>>> probably
>>>>> a separate bug that only shows up now that the first one has been
>>>>> fixed.
>>>>>
>>>>> It'll take a couple days to get back to this.
>>>>>
>>>>> Peter
>>>>>
>>>>>
>>>>> On Thu, Jul 4, 2013 at 9:38 AM, Daniele Alessandrelli <
>>>>> [email protected]> wrote:
>>>>>
>>>>> > Thank you for the quick patch.
>>>>> > However, there are still some problems. For example, when I compile
>>>>> > the attached code (sorry, I can't replicate the problem with simple
>>>>> > code), I get the following error:
>>>>> > /tmp/ccNaHhxW.s: Assembler messages:
>>>>> > /tmp/ccNaHhxW.s:1427: Error: Repeated instruction must have register
>>>>> > mode operands
>>>>> >
>>>>> > The problematic code snippet is from line 699 to 706:
>>>>> > ...
>>>>> >         case COAP_OPTION_BLOCK1:
>>>>> >           coap_pkt->block1_num =
>>>>> coap_parse_int_option(current_option,
>>>>> > option_len);
>>>>> >           coap_pkt->block1_more = (coap_pkt->block1_num & 0x08)>>3;
>>>>> >           coap_pkt->block1_size = 16 << (coap_pkt->block1_num &
>>>>> 0x07);
>>>>> >           coap_pkt->block1_offset = (coap_pkt->block1_num &
>>>>> > ~0x0000000F)<<(coap_pkt->block1_num & 0x07);
>>>>> >           coap_pkt->block1_num >>= 4;
>>>>> >           printf("Block1 [%lu%s (%u B/blk)]\n", coap_pkt->block1_num,
>>>>> > coap_pkt->block1_more ? "+" : "", coap_pkt->block1_size);
>>>>> >           break;
>>>>> > ...
>>>>> >
>>>>> > Part of the produced assembly code is the following:
>>>>> > ...
>>>>> >         mov     r12, r4
>>>>> >         and     #7, r4
>>>>> >         mov.b   r4, r11
>>>>> >         mov     #16, @r1
>>>>> >         cmp.b   #0, r11
>>>>> >         jeq     .L158
>>>>> >         add.b   #-1, r11
>>>>> >         .rpt    r11
>>>>> >         rlax    @r1
>>>>> > .L158:
>>>>> >         mov     @r1, 96(r9)
>>>>> > ...
>>>>> >
>>>>> > The invalid instruction seems to be the following
>>>>> > .rpt    r11
>>>>> > rlax    @r1
>>>>> >
>>>>> > Some notes:
>>>>> > - the code is taken from Contiki, so perhaps you can test it
>>>>> personally
>>>>> > - if the final printf() is removed, the code compiles (i.e., the
>>>>> > generated assembly is correct) and works as expected.
>>>>> >
>>>>> > Regards.
>>>>> >
>>>>> > Daniele
>>>>> >
>>>>> > On Wed, Jul 3, 2013 at 8:30 PM, Peter Bigot <[email protected]> wrote:
>>>>> > > Thanks for the ticket and the reproducing code.  I've attached to
>>>>> the
>>>>> > ticket
>>>>> > > a (second attempt at a) patch that I believe fixes this.  It has
>>>>> not
>>>>> > > undergone significant testing but I'll be using it in my own work.
>>>>> > >
>>>>> > > Those of you playing along at home might find the patch attached to
>>>>> > > https://sourceforge.net/p/mspgcc/bugs/352/ useful as well.  They
>>>>> are to
>>>>> > the
>>>>> > > 20120911 development release, and are unsupported, but are most of
>>>>> what
>>>>> > > would have qualified as patches if that were an LTS release.  If
>>>>> you
>>>>> > apply
>>>>> > > them and build a system, please update the version number in some
>>>>> way so
>>>>> > > you're reminded they're not standard builds.
>>>>> > >
>>>>> > > Sorry, I don't provide instructions or support for applying
>>>>> patches to
>>>>> > > mspgcc.
>>>>> > >
>>>>> > > Peter
>>>>> > >
>>>>> > >
>>>>> > > On Wed, Jul 3, 2013 at 11:38 AM, Daniele Alessandrelli
>>>>> > > <[email protected]> wrote:
>>>>> > >>
>>>>> > >> I opened the ticket:
>>>>> > >> https://sourceforge.net/p/mspgcc/bugs/357/
>>>>> > >>
>>>>> > >> Thank you for your time.
>>>>> > >>
>>>>> > >> Daniele
>>>>> > >>
>>>>> > >>
>>>>> > >> On Wed, Jul 3, 2013 at 5:20 PM, Peter Bigot <[email protected]>
>>>>> wrote:
>>>>> > >>>
>>>>> > >>> That looks like a bug.  Only happens on CPUX architectures.  If
>>>>> you
>>>>> > open
>>>>> > >>> up a ticket on https://sourceforge.net/p/mspgcc/bugs/ I may be
>>>>> able
>>>>> > to look
>>>>> > >>> at it some time.
>>>>> > >>>
>>>>> > >>> Peter
>>>>> > >>>
>>>>> > >>>
>>>>> > >>> On Wed, Jul 3, 2013 at 7:37 AM, Daniele Alessandrelli
>>>>> > >>> <[email protected]> wrote:
>>>>> > >>>>
>>>>> > >>>> Hi everybody,
>>>>> > >>>>
>>>>> > >>>> I noticed a strange behavior when executing certain shift
>>>>> operations
>>>>> > and
>>>>> > >>>> I
>>>>> > >>>> wonder whether this is because of a compiler bug or just my
>>>>> ignorance
>>>>> > in
>>>>> > >>>> low-level C.
>>>>> > >>>>
>>>>> > >>>> For example, when compiling (with no optimization) and then
>>>>> executing
>>>>> > >>>> the
>>>>> > >>>> following lines of code the result I obtain is 16 instead of 64:
>>>>> > >>>>
>>>>> > >>>> uint32_t  u32_var;
>>>>> > >>>>
>>>>> > >>>> int main(void)
>>>>> > >>>> {
>>>>> > >>>>     int tmp;
>>>>> > >>>>     ...
>>>>> > >>>>     u32_var = 0xa;
>>>>> > >>>>     tmp = 16 << (u32_var & 0x07);
>>>>> > >>>>     printf("tmp: %d\n", tmp);
>>>>> > >>>>     ...
>>>>> > >>>> }
>>>>> > >>>>
>>>>> > >>>> However, if I change the type of tmp form "int" to "unsigned
>>>>> int" the
>>>>> > >>>> result is correct (i.e., 64).
>>>>> > >>>>
>>>>> > >>>> This is assembly code generated when tmp is defined as int
>>>>> (i.e., when
>>>>> > >>>> the
>>>>> > >>>> result is wrong).
>>>>> > >>>>
>>>>> > >>>>     5c44:       b2 40 0a 00     mov     #10,    &0x1c02 ;#0x000a
>>>>> > >>>>
>>>>> > >>>>     5c48:       02 1c
>>>>> > >>>>
>>>>> > >>>>     5c4a:       82 43 04 1c     mov     #0,     &0x1c04 ;r3
>>>>> As==00
>>>>> > >>>>
>>>>> > >>>>     5c4e:       1e 42 02 1c     mov     &0x1c02,r14
>>>>> > >>>>
>>>>> > >>>>     5c52:       1f 42 04 1c     mov     &0x1c04,r15
>>>>> > >>>>
>>>>> > >>>>     5c56:       0f 4e           mov     r14,    r15
>>>>> > >>>>
>>>>> > >>>>     5c58:       3f f0 07 00     and     #7,     r15     ;#0x0007
>>>>> > >>>>
>>>>> > >>>>     5c5c:       3e 40 10 00     mov     #16,    r14     ;#0x0010
>>>>> > >>>>
>>>>> > >>>>     5c60:       4f 4f           mov.b   r15,    r15
>>>>> > >>>>
>>>>> > >>>>     5c62:       7f f0 0f 00     and.b   #15,    r15     ;#0x000f
>>>>> > >>>>
>>>>> > >>>>     5c66:       84 4e fc ff     mov     r14,    -4(r4)
>>>>>  ;0xfffc(r4)
>>>>> > >>>>
>>>>> > >>>>     5c6a:       4f 93           tst.b   r15
>>>>> > >>>>
>>>>> > >>>>     5c6c:       03 24           jz      $+8             ;abs
>>>>> 0x5c74
>>>>> > >>>>
>>>>> > >>>>     5c6e:       7f 53           add.b   #-1,    r15     ;r3
>>>>> As==11
>>>>> > >>>>
>>>>> > >>>>     5c70:       cf 18 0e 5e     .rpt    r15
>>>>> > >>>>
>>>>> > >>>>                                 addx    r14,    r14
>>>>> > >>>>
>>>>> > >>>>     5c74:       14 12 fc ff     push    -4(r4)
>>>>>  ;0xfffc(r4)
>>>>> > >>>>
>>>>> > >>>>     5c78:       30 12 9a 66     push    #26266          ;#0x669a
>>>>> > >>>>
>>>>> > >>>>     5c7c:       b0 12 ae 5c     call    #0x5cae
>>>>> > >>>>
>>>>> > >>>>
>>>>> > >>>> As you can see, at address 0x5c66, register 14 (containing 16)
>>>>> is
>>>>> > stored
>>>>> > >>>> in
>>>>> > >>>> memory before being shifted. The stored valued (i.e., 16) is
>>>>> then
>>>>> > pushed
>>>>> > >>>> in
>>>>> > >>>> the stack (i.e., passed as an argument to the printf()
>>>>> function).
>>>>> > >>>>
>>>>> > >>>> I have a similar problem also when using -Os, but I can't
>>>>> replicate it
>>>>> > >>>> with
>>>>> > >>>> simple code because of the optimization. However, if needed, I
>>>>> can
>>>>> > post
>>>>> > >>>> the
>>>>> > >>>> (large) source code that is giving me this problem.
>>>>> > >>>>
>>>>> > >>>> The version of msp430-gcc that I am using is:
>>>>> > >>>> msp430-gcc (GCC) 4.7.0 20120322 (mspgcc dev 20120911)
>>>>> > >>>>
>>>>> > >>>> Thank you for any help you can provide.
>>>>> > >>>>
>>>>> > >>>> Regards.
>>>>> > >>>>
>>>>> > >>>> Daniele
>>>>> > >>>>
>>>>> > >>>>
>>>>> > >>>>
>>>>> >
>>>>> ------------------------------------------------------------------------------
>>>>> > >>>> This SF.net email is sponsored by Windows:
>>>>> > >>>>
>>>>> > >>>> Build for Windows Store.
>>>>> > >>>>
>>>>> > >>>> http://p.sf.net/sfu/windows-dev2dev
>>>>> > >>>> _______________________________________________
>>>>> > >>>> Mspgcc-users mailing list
>>>>> > >>>> [email protected]
>>>>> > >>>> https://lists.sourceforge.net/lists/listinfo/mspgcc-users
>>>>> > >>>>
>>>>> > >>>
>>>>> > >>
>>>>> > >
>>>>> >
>>>>>
>>>>>
>>>>> ------------------------------------------------------------------------------
>>>>> This SF.net email is sponsored by Windows:
>>>>>
>>>>> Build for Windows Store.
>>>>>
>>>>> http://p.sf.net/sfu/windows-dev2dev
>>>>> _______________________________________________
>>>>> Mspgcc-users mailing list
>>>>> [email protected]
>>>>> https://lists.sourceforge.net/lists/listinfo/mspgcc-users
>>>>>
>>>>>
>>>>
>>>
>>
>

------------------------------------------------------------------------------
See everything from the browser to the database with AppDynamics
Get end-to-end visibility with application monitoring from AppDynamics
Isolate bottlenecks and diagnose root cause in seconds.
Start your free trial of AppDynamics Pro today!
http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk

_______________________________________________
Mspgcc-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/mspgcc-users