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: receive delay 1 second

Part Number: CC1310

HI:

I use the easylink  driver to run a transmiting / receiving application, everything seems well and I can use it to change the frequency and receive or transmit data successful until I found a problem: If I try to receive a continous packets at a period which below 1 second, it will loss pacekts!  Then I found that the time between the command (CMD_PROP_RX_ADV) I send  with the time it run to rxDoneCallback  is neerly 1 second! No matter the packts is less than 10bytes or bigger  than 300bytes, this delay is almost about 1 second. I don't know why. Anyone can give me an advice?

TI-RTOS for cc13xx and cc26xx version:   2.21.0.06

static rfc_CMD_PROP_RX_ADV_t EasyLink_cmdPropRxAdv = {
.commandNo = CMD_PROP_RX_ADV,
.status = 0x0000,
.pNextOp = 0,
.startTime = 0x00000000,
.startTrigger.triggerType = TRIG_NOW,
.startTrigger.bEnaCmd = 0x0,
.startTrigger.triggerNo = 0x0,
.startTrigger.pastTrig = 0x0,
.condition.rule = 0x1,
.condition.nSkip = 0x0,
.pktConf.bFsOff = 0x0,
.pktConf.bRepeatOk = 0x0,
.pktConf.bRepeatNok = 0x0,
.pktConf.bUseCrc = 0x0,//0x1,
.pktConf.bCrcIncSw = 0x0,
.pktConf.bCrcIncHdr = 0x0,//0x1,
.pktConf.endType = 0x0,
.pktConf.filterOp = 0x0,//0x1,
.rxConf.bAutoFlushIgnored = 0x1,//0x0,
.rxConf.bAutoFlushCrcErr = 0x1,//0x0,
.rxConf.bIncludeHdr = 0x0,//0x1,
.rxConf.bIncludeCrc = 0x0,//0x0,
.rxConf.bAppendRssi = 0x0,
.rxConf.bAppendTimestamp = 0x0,
.rxConf.bAppendStatus = 0x1,//0x0,
.syncWord0 = 0x930b51de,
.syncWord1 = 0,
.maxPktLen = 1024,//0,
.hdrConf.numHdrBits = 0,//8,
.hdrConf.lenPos = 0,
.hdrConf.numLenBits = 0,//8,
.addrConf.addrType = 0,
.addrConf.addrSize = 0,
.addrConf.addrPos = 0,
.addrConf.numAddr = 1,
.lenOffset = 0,
.endTrigger.triggerType = TRIG_REL_START,
.endTrigger.bEnaCmd = 0x0,
.endTrigger.triggerNo = 0x0,
.endTrigger.pastTrig = 0x0,
.endTime = EasyLink_ms_To_RadioTime(15),
.pAddr = 0,
.pQueue = 0,
.pOutput = 0,
};

  • Hi
    Not sure I understand what time you are referring and how you are measuring the time. The time from CMD_PROP_RX_ADV is executed (radio enters RX) until you receive the callback will depend on when you transmit your packet, not only how long it is.
    A 300 bytes long packet takes approx. 48 ms to transmit and a 10 bytes long packet takes 1.6 ms.
    If you are measuring a delay of 1 s from entering RX until you get the callback, that simply means that your transmitter starts transmitting nearly a second after the receiver entered RX.
    Siri
  • Hi Siri:

    Thank you for your reply.The time what I mean is as follows:(the yellow part)

    SND: Send command RX_ADV

    RXNS: Run rxcallback and send next RX_ADV command

                       15ms                     15ms                      15ms                                                                                                         neerly  1000ms

               |--------------------- |--------------------- |---------------------|                                         ........                      |-----------------------------------------------------------------------------------------------|

             SND                      RXNS                  SND                     RXNS                                                          SND                                                                                                                    RXNS

    As the paramter  I set, 

    EasyLink_cmdPropRxAdv.endTrigger.triggerType = TRIG_REL_START;
    EasyLink_cmdPropRxAdv.endTime = EasyLink_ms_To_RadioTime(15)

    If the RF core doesn't  detect the preamble and sync in 15ms, it will end the current rx operation and then I start to send the next RX_ADV, active the next receive operation. But when it detect the preamble and  the sync, I find that the time interval becomes strange, and it seems it takes a long time (1s is really too long for my application) for the RF core to capture the whole packets, it looks like that  the receive operation has a bad real-time performance and  it cannot receive continous packets who has a period small than 1s( loss packts) .

    I use annother receiver (not cc1310) to receive the packets that come from the same transmitter, it can receive packets without 1s delay( far less than 1s), so  I am sure not the problem of the tratrnsmitter.

  • It seems that the system is stuck for about 1s when the rf core received the packets.
    What's wrong with it and what the cc1310 do in this "missing 1s"?
  • You are using a fairly old version of the example. Could you download v1.4 of the SDK and see if you see the same there? If you do, please post your code (project) and how we could see the the same using the provided software.
  • Hi TER:

    I didn't find any improvement about the Easylink receive operation in the new version, so I didn't update to the latest version. Since I am stuck in this problem for neerly a week and have no other idear to solve it, so I am trying to use the latest version (simplelink 1.4.0) in my application, but  there comes a problem:

    "../CC1310DK_7XD_TIRTOS.cmd", line 92: error #10099-D: program will not fit into available memory. run placement with alignment fails for section ".data" size 0xfd7 . Available memory ranges:
    SRAM size: 0x5000 unused: 0x786 max hole: 0x748
    error #10010: errors encountered during linking; "rfEasyLinkNp_CC1310DK_7XD_tirtos_ccs.out" not built

    Follow is my .cmd file:

    /*
    * ======== CC1310DK_7XD.cmd ========
    * CC26x0F128 PG2 linker configuration file for Code Composer Studio
    */

    /* Override default entry point. */
    --entry_point ResetISR
    /* Allow main() to take args */
    --args 0x8
    /* Suppress warnings and errors: */
    /* - 10063: Warning about entry point not being _c_int00 */
    /* - 16011, 16012: 8-byte alignment errors. Observed when linking in object */
    /* files compiled using Keil (ARM compiler) */
    --diag_suppress=10063,16011,16012

    /* The starting address of the application. Normally the interrupt vectors */
    /* must be located at the beginning of the application. */


    #define FLASH_PAGE_SIZE 0x1000
    #define FLASH_ADDR 0x0
    #define FLASH_SIZE 0x20000
    #define FLASH_APPL_ADDR FLASH_ADDR
    #define FLASH_APPL_SIZE (30 * FLASH_PAGE_SIZE) // 30 pages for the application
    #define FLASH_DATA_ADDR (FLASH_APPL_ADDR + FLASH_APPL_SIZE)
    #define FLASH_DATA_SIZE (1 * FLASH_PAGE_SIZE) // 1 page for the config data
    #define FLASH_CCFG_ADDR (FLASH_DATA_ADDR + FLASH_DATA_SIZE)
    #define FLASH_CCFG_SIZE (1 * FLASH_PAGE_SIZE) // 1 page for the ccfg
    #define RAM_ADDR 0x20000000
    #define RAM_SIZE 0x5000

    //__FLASH_DATA_ADDR = FLASH_DATA_ADDR;
    /* System memory map */

    MEMORY
    {
    /* Application stored in and executes from internal flash */
    FLASH_APPL (RX) : origin = FLASH_APPL_ADDR, length = FLASH_APPL_SIZE
    /* User-defined data section in flash */
    FLASH_DATA (RX) : origin = FLASH_DATA_ADDR, length = FLASH_DATA_SIZE
    /* CCFG data */
    FLASH_CCFG (RX) : origin = FLASH_CCFG_ADDR, length = FLASH_CCFG_SIZE
    /* Application uses internal RAM for data */
    SRAM (RWX) : origin = RAM_ADDR, length = RAM_SIZE
    }

    /* Section allocation in memory */

    SECTIONS
    {
    .text : > FLASH_APPL
    .const : > FLASH_APPL
    .constdata : > FLASH_APPL
    .rodata : > FLASH_APPL
    .cinit : > FLASH_APPL
    .pinit : > FLASH_APPL
    .init_array : > FLASH_APPL
    .emb_text : > FLASH_APPL
    .flashdata : > FLASH_DATA
    .ccfg : > FLASH_CCFG (HIGH)

    .data : > SRAM
    .bss : > SRAM
    .sysmem : > SRAM
    .stack : > SRAM (HIGH)
    .nonretenvar : > SRAM
    }

    I just want to save a page of user config data in the flash. How to solve it?

  • If you want to save datato flash, have you tried with the NVS driver that was released in SDK 1.4?
  • I have accomplshed the function saving data in flash with the flash operation function in the flash driver and don't want to change it.
    And the .cmd file works well while I use the TI RTOS for cc13xx and cc26xx 2.21.0.06. Now can you give me an advice on how to sovle the compile problem:
    "../CC1310DK_7XD_TIRTOS.cmd", line 92: error #10099-D: program will not fit into available memory. run placement with alignment fails for section ".data" size 0xfd7 . Available memory ranges:
    SRAM size: 0x5000 unused: 0x786 max hole: 0x748
    error #10010: errors encountered during linking; "rfEasyLinkNp_CC1310DK_7XD_tirtos_ccs.out" not built

    or could you tell me in which case the RF core will delay for a period of time to get the rx packet while it have detect the preamble?
  • Actually, I have routed the RAT_GPO1 signal to a general I/o pin,  and the i/o level always on high level for  about 600ms and turn  low level for   about 400ms  while the transmitter was sending packets at a period of 1s. Since the description of the RAT_GPO1 is:  

    Goes high when sync word is detected and low either when the packet has been received or reception has been aborted

    So I thought that the time between the time when the sync word is detected and the time  when the packet has been received is about 600ms. But  how could this happen since this delay is too long to be accepted.

  • HI:
    Actually my system works well,it can transmit/receive packets successful, but I think the time that the RF core capture a packts is a bit slow. To avoid some mistake caused by my poor description, I just draw such a rough sketch:
    |<----------------------------------RX----------------------------------->|
    |........................|_________________________________|
    1 2 3
    1:start a rx operation(send a RX_ADV command)
    2: detect the preamble+sync
    3: Radio CPU finished putting the received data into the entry
    I mean the time between 1 and 3 is to long, and I don't know whether it is a normal phenomenon or something is wrong and I need to improve it.
    Follow is my test result:
    pktLen = 1024
    when the symbolrate is 9600, the interval(1->3) is about 430ms;
    when the symbolrate is 19200, the interval(1->3) is about 850ms;
    Cause my application must use the symbolrate 9600 and it cannot tolerance the delay is more than 500ms, is there anything can be do to improve such a poor performance?