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 <softtro...@gmail.com> 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 <big...@acm.org> 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 <softtro...@gmail.com> 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 <big...@acm.org> 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 <
>>>> daniele.alessandre...@gmail.com> 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 <big...@acm.org> 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
>>>> > > <daniele.alessandre...@gmail.com> 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 <big...@acm.org>
>>>> 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
>>>> > >>> <daniele.alessandre...@gmail.com> 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
>>>> > >>>> Mspgcc-users@lists.sourceforge.net
>>>> > >>>> 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
>>>> Mspgcc-users@lists.sourceforge.net
>>>> 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
Mspgcc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mspgcc-users
