This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

MSP430 rf2560 issue

Hello,

I have recently been modifying the msp430 rf2560 accelerometer program to send all three axis of accelerometer data separated by a comma. The appl_sdk.c file was altered to increase the appl_spp_data_buffer from 4 to 10. The sdk_pl.c file was then changed to the code below.

    buffer[0] = accl_x;
    buffer[1] = (accl_x >> 8);
    buffer[2]  = accl_parse;
    buffer[3]  = (accl_parse >> 8);
    buffer[4] = accl_y;
    buffer[5] = (accl_y >> 8);
    buffer[6]  = accl_parse;
    buffer[7]  = (accl_parse >> 8);
    buffer[8] = accl_z;
    buffer[9] = (accl_z >> 8);

accl_parse was declared as a int16 same as accl_x, accl_y and accl_z, and initialized to 0x2c (ascii code for comma). The interesting thing is that the comma is never sent or at least it never shows up in the hyperterminal window. My questions for this post come from the stepping through the program and looking at the IAR disassembly  window.  buffer[0] = accl_x command equates to  mov.b  R14,0x0(R10) , and the buffer[1]=accl_x>>8 equates to swpb R14 followed by mov.b R14,0x1(R10). When I step through the program and execute these commands I can see the swap byte command execute but the value of register 10 is never altered (it is always 0332A). The fact that I never see the value in R10 change when data is being moved there is rather confusing to me, and I am not sure whether or not I am interpreting the code commands correctly. I even changed the code back to the original buffer size of 4 and only sent the x and y data and the same situation arises. So my question is obviously why am I not seeing the value of R10 changing with the mov.b instruction?

My second question is why would accl_parse value not show up in the terminal window with the acclerometer data? I never see a comma or a 0x2c (if im viewing with a hex terminal plugin).

Thanks in advance for anyone who can help.

~MJ

 

  • Mark Joseph said:
    buffer[0] = accl_x command equates to  mov.b  R14,0x0(R10) , and the buffer[1]=accl_x>>8 equates to swpb R14 followed by mov.b R14,0x1(R10). When I step through the program and execute these commands I can see the swap byte command execute but the value of register 10 is never altered (it is always 0332A).

    The value is not moved to R10, it is move to teh address R10+0 and R10+1. R10 contains the address of the low byte of buffer[0]. Or the base address of the array, which is the same in this case.
    MOV.B x, R10 moves x to R10. MOV.B x, y(r10) moves x to the memory location whose address is at (R10+y)

    So the values are going to 0x332A and 0x332B. Ans since it is MOV.B and not MOV/MOV.W, only the low byte of x is moved to a byte destination (MOV would move a 16 bit value to an even word destination - ignoring the LSB of the address!)

  • Hi Mark Joseph,

        Can you please try the below code and  change the appl_spp_data_buffer  to 8. Now Please check in the serial terminal.

        buffer[0] = accl_x;
        buffer[1] = (accl_x >> 8);
        buffer[2]  = ',';
        buffer[3] = accl_y;
        buffer[4] = (accl_y >> 8);
        buffer[5]  = ',';
        buffer[6] = accl_z;
        buffer[7] = (accl_z >> 8);

     


    Regards

  • Thank you Jens-Michael. I looked through the msp430x5xx instruction set and understand the usage of R10. Now on to the real issue at hand....

  • srisenthilkumar chandrasekara,

    Thank you for the response but it is unfortunately something I have already tried, and does not work.

  • Mark Joseph said:
    Now on to the real issue at hand

    Yep, the R10 thing was a red herring. It seems the buffer is filled correctly. The only obvious explanation that's lef tis that the buffer isn't sent properly.
    Expanding the buffer form 4 to 10 elements isn't enough. The send mechanism needs ot be changed too, to support more than 4 bytes.
    I don't know the original code, nor do I know your exact changes (if any), so I cannot tell.

  • Jens-Michael,

    Thank you very much for your answer. I have found my issue and resolved the problem (of which there were several). It was indeed the need to adjust the packet size to accommodate the new data, and since I was after the raw accelerometer data, there was no need for int16 or the shift into the buffer. Thanks to everyone for all the advice

  • Mark Joseph,

    could you plese describe what changes are needed when changing the packet size? I'm working on a similar problem and need to send more then 4 bytes of data, which is buffer default.

    Regards,

    BJ

**Attention** This is a public forum