• State Resolved
  • Locked Locked
  • Replies 3 replies
  • Subscribers 54 subscribers
  • Views 168 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

CC1312R: Unable to send, in certain cases.

Gullik Webjorn
Intellectual 570 points
Part Number: CC1312R


Tool/software:

Hello,

I have a problem with my program based on the rfUARTbridge example.

I have broken out the "cancel receive, send packet, issue receive" part of the example and placed it in a separate function SendPacket.

This does not seem to change behavior of the example.

I have subsequently added functions that issue a  SendPacket when things happen.

This also works nicely, as expected.

However, I have now added several functions that add data to send, and ONE of them misbehaves, in that the 2:d rf function, transmitting never completes.
 
I felt it should be easy to test on the status of the transmit, but there IS no status

Program does not halt or crash, it just executes inside some library

I printed out the result of the preceding RF_cancelcmd and it always reports 131, 0x83 when
the cancel works properly, however when I inject a packet from another part of the code by calling sendpacket, the cancel returns 3.

So, to me it seems as the cancel fails for some reason and thus a subsequent send
hangs.

I have checked all the message variables, and the count, and I can see that the
RF_PropTX looks OK in all cases.

One difference is that the status word of the TX that is usually 0 when I issue (before) the transmit, has a value of 0x3400 BEFORE the transmit, I figured it was for radio processor
or driver code to update (W) and for a user program to read (R) so how come it has a value (last status?), and does that matter?

Does anyone have an idea of what to look at?

void SendPacket(char *message,int count){

       if (count >= 254)
           count = 254;

       RF_cmdPropTx.pktLen = count;
       int i,status;
       for (i=0; i<count; i++)
       {
           packet[i] = message[i];
       }
//       delay(4);
//       xprint_schar(GetRssi());
//       xprint("\n");
//       while(RF_getRssi(rfHandle) >= -100) {}   // poor mans cca, hang here until rssi is below -100,
       /*Cancel the ongoing command*/
       RF_cancelCmd(rfHandle, rfPostHandle, 1); // first stop receive

       /*Send packet*/
       status = RF_runCmd(rfHandle, (RF_Op*)&RF_cmdPropTx, RF_PriorityNormal, NULL, 0); // then send packet
       if(status != 2) {
           xprint("what?");
       }
       Sent++;
       /* Toggle green led to indicate TX */

       GPIO_toggle(CONFIG_GPIO_GLED);

       /* Resume RF RX */
       rfPostHandle = RF_postCmd(rfHandle, (RF_Op*)&RF_cmdPropRx,    //third, restart receive
                                                            RF_PriorityNormal, &ReceivedOnRFcallback,
                                                            RF_EventRxEntryDone);
}

Regards,

Gullik

  • 0
    Intellectual 570 points

    This is more in detail what happens:

    When executing the RF_cancelcmd the rfPostHandle parameter is incremented by 2 each time the function is called. I guess this is the way the radio library

    keeps track of the number / identity of the actual operation in the que, which f I understand correctly is a RF receive with callback, They all are or should be.

    When I enable the function that causes the error, the value  of rfPostHandle is 16384. I guess there is no such highnumbered entry in the execution queue, thus

    the command status is 3 rather than 0x83. It is a bit hard to reverse translate the number / bit to a error keyword in some H file.

    So, now the question is: Who modifies the rfPostHandle, and is this a simple "buffer overrun" problem in my code?

    Documentation refers to rfPostHandle as a "command handle", however it does not seem to be a structure,

    but a simple int16_t.......... Puzzled.....

    Getting there......

    Gullik

  • +1 in reply to Gullik Webjorn
    Intellectual 570 points

    This is more in detail what happens:

    When executing the RF_cancelcmd the rfPostHandle parameter is incremented by 2 each time the function is called. I guess this is the way the radio library

    keeps track of the number / identity of the actual operation in the que, which f I understand correctly is a RF receive with callback, They all are or should be.

    When I enable the function that causes the error, the value  of rfPostHandle is 16384. I guess there is no such highnumbered entry in the execution queue, thus

    the command status is 3 rather than 0x83. It is a bit hard to reverse translate the number / bit to a error keyword in some H file.

    So, now the question is: Who modifies the rfPostHandle, and is this a simple "buffer overrun" problem in my code?

    Documentation refers to rfPostHandle as a "command handle", however it does not seem to be a structure,

    but a simple int16_t.......... Puzzled.....

    Getting there......

    Sooo.... I set a watchpoint at the rfPostHandle. I seem to get a hit, but I cannot debug, the proceed arrow is greyed out, and trying to

    display variables does not work.....Is this the way a watchpoint should work, I thought I should be able to see the statement that actually modified the variable........

    Resolution: The variable rfPostHandle was modified by a spi transaction. Since this is probably NOT handled by the jtag debug, it was invisible to me. Debugging with ordinary breakpoints until I found an error in a buffer specification for the SPI resolved the problem. So, note that watchpoints cannot handle dma modifications of memory. I learned something new....

    Regards,

    Gullik

  • +1
    TI__Guru* 82431 points

    Hi Gullik,

    Not sure how to best help you but here is  some debug advice:

    1. You can add the RF driver files to your workspace. When you rebuild the example and start a new debug session it should no longer execute from the rflib library, but from the source file in your workspace.

    2. Remember that the RF core is an independent core, and hitting a breakpoint in the c code running on the M4 will not halt the RF core. This can cause some seemingly strange behavior when trying to debug the radio.

    3. If you're trying to set a breakpoint but CCS moves it to a lower line, it usually means the line is optimized out in the assembly code. Two solutions:

    a) You can adjust the optimization of your function. (Also if using LTO turn this off).

    b) You can open disassembly view and set breakpoints directly in the assembly code.

    Hope this helps!

    Cheers,

    Marie H