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 <big...@acm.org> 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 <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
