Re: [Mspgcc-users] msp430-gcc 4.7 bug with shifts?
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 ~0x000F)(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 .rptr11 rlax@r1 .L158: mov @r1, 96(r9) ... The invalid instruction seems to be the following .rptr11 rlax@r1
Re: [Mspgcc-users] 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 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 ~0x000F)(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
Re: [Mspgcc-users] msp430-gcc 4.7 bug with shifts?
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
~0x000F)(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
.rptr11
rlax@r1
.L158:
mov @r1, 96(r9)
...
The invalid instruction seems to be the following
.rptr11
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
