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.

CC1310: CC1310 is set to long receiving mode (bRepeatOk and bRepeatNok are both 1). After the RF receives the data, the output through the serial port is normal. However, after the serial port receives the data, the RF switches and sends an exception (call

Part Number: CC1310

Hi team,

The SDK used is simplelink_cc13x0_sdk_4_20_02_07, and the code compilation environment is IAR.

Using TI-RTOS, refer to rfPacketTx and rfPacketRx

The customer's current project is to power up the CC1310 to the long RX state. After receiving the data, it outputs information through the serial port. After the serial port receives the external command, it will cancel the current RX state and switch to TX and send the data. After the transmission is completed, the long RX mode will continue. Now there is no problem with RF reception, but once the RX command is canceled, calling RF_runCmd(rfHandle, (RF_Op*)&RF_cmdPropTx, RF_PriorityNormal, NULL, 0) will cause the device to restart. I determined through debugging that the cancellation status was successful. It feels like restarting is a probabilistic problem, because I have multiple boards of our own. One of them can execute the TX command normally, but the other one cannot send the debugging. It is found that every time RF_runCmd(rfHandle, (RF_Op*)&RF_cmdPropTx, RF_PriorityNormal, NULL is called) , 0) and then restart.

Here is some configuration code:

if( RFQueue_defineQueue(&dataQueue,
rxDataEntryBuffer,
sizeof(rxDataEntryBuffer),
NUM_DATA_ENTRIES,
MAX_LENGTH + NUM_APPENDED_BYTES)){ /* Failed to allocate space for all data entries */
while(1);
}
/* Modify CMD_PROP_RX command for application needs */
/* Set the Data Entity queue for received data */
RF_cmdPropRx.pQueue = &dataQueue;
/* Discard ignored packets from Rx queue */
RF_cmdPropRx.rxConf.bAutoFlushIgnored = 1;
/* Discard packets with CRC error from Rx queue */
RF_cmdPropRx.rxConf.bAutoFlushCrcErr = 1;
/* Implement packet length filtering to avoid PROP_ERROR_RXBUF */
RF_cmdPropRx.maxPktLen = MAX_LENGTH;
RF_cmdPropRx.pktConf.bRepeatOk = 1;
RF_cmdPropRx.pktConf.bRepeatNok = 1;
RF_cmdPropRx.rxConf.bAppendRssi = 1;
RF_cmdPropRx.rxConf.bAppendStatus = 0;

Function to cancel the call: RF_cancelCmd(rfHandle, rfCmdHandle, 0); // Terminate reception

Send the called function: RF_runCmd(rfHandle, (RF_Op*)&RF_cmdPropTx, RF_PriorityNormal, NULL, 0);

Thanks & Best regards,

Yolande

  • Hi Yolande,

    Is this a custom board or is it observed on CC1310 launchpad?

    I would ask the customer to reproduce this issue on CC1310 launchpad. This would let us know if it is a board issue or actually a bug in software. 

    Regards,

    Sid 

  • Hi Sid,

    It's the customer's own board, and the strange thing is that one of them works fine, but the others don't.
    The customer has confirmed that the hardware and software are exactly the same.
    What is the reason for this?
    When debugging to RF_runCmd(), the compiler will report an error and force it to exit debugging mode. How to troubleshoot?

    Thanks &  Best regards,

    Yolande

  • Hi Sid,

    Does the manual welding of the customer's own board have a big impact on the RF part? Today the customer used a machine to paste a piece of it and so far the customer haven't found any problems with restarting. One of the boards welded by hand before worked normally, and the others were all reboot issues.

    Regards,

    Yolande

  • Hi Yolande, 

    I asked if the issue could be reproduced on a launchpad for this exact reason. If it is reproducible on a launchpad, it points to a software issue. If the same software works correctly on a launchpad, then it is more likely that the issue is from the board itself.

    The reset could be because of not having good soldering on the power/reset input. 

    Regards

    Sid

  • Hi Sid,

    Customer follow-up is below:

    I don’t have a launchpad on hand at the moment. I made my own board based on the reference design. In addition, I tested in the morning and found that the board that I had soldered by hand before worked normally in a certain frequency band, But after I switch the working frequency band, it will cause the chip to restart.
    This board of mine needs to be attached to our motherboard for use (similar to the serial port transparent transmission module). The IPEX socket I have connected to the board will restart when I do not connect the external antenna or connect the external antenna. I refer to the RF part. The official 433M part is designed. The working frequency band I configured in the software is between 431-527. I feel that it is caused by interference. The project is about to be mass-produced. Thank you for your help!!

    Thanks &  Best regards,

    Yolande

  • Hi Yolande,

    I will ask for help from our HW team, but I also want to know what is the error that the debugger reports before exiting debug mode. 

    When debugging to RF_runCmd(), the compiler will report an error and force it to exit debugging mode. How to troubleshoot?

    Regards,

    Sid

  • Hi Sid,

    These are error messages:

    In the morning, the customer discovered that calling the TxAdv command would also cause a restart.

    Thanks &  Best regards,

    Yolande

  • Hi Sid,

    Could you please help me take a look at the schematic diagram and layout? Is there any problem?

    Thanks &  Best regards,

    Yolande

  • Hi Yolande,

    I have notified the HW engineer. But to make sure, Is this statement still true that the issue only happens on hand soldered samples? 

    Today the customer used a machine to paste a piece of it and so far the customer haven't found any problems with restarting

    If the issue is not reproduced on machine soldered samples, I do not think it is a SW bug, but rather a HW issue. I will let the HW engineer respond here.

    Regards,
    Sid

  • Hi Sid,

    Machine-attached problems can also happen, but the customer do have a hand-soldered piece with the same program running fine (but there will be restarts after switching frequency bands, and it works fine in a certain frequency band), so the customer think there should be some hardware problems.Looking forward to the hardware engineer's reply.

    Thanks & Best regards,

    Yolande

  • Hi Yolande,

    Please can the customer submit their design for review using: Sub-1 GHz Design Review Submission: https://www.ti.com/tool/SIMPLELINK-SUB1GHZ-DESIGN-REVIEWS

    We need more information than just the top layer of the design and this method is confidential - please can they link to this thread in the request form (or submission email) so that I know it relates to this issue.

    Regards,

    Zack