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.

TIDA-00484: Board and FW Debug

Part Number: TIDA-00484
Other Parts Discussed in Thread: CC1310

Hello,

I am debugging a TIDA-00484 clone board. Here is the situation and my questions. Any help is appreciated. Let me give full details (apologize for long posting with all details)

TIDA-00484 board is connected to SmartRF06 evaluation board via 10-pin ARM Cortex Debug Connector and I can see the board detects CC1310 on target TIDA-00484 board. I have compiled all the code (clean build) and flashed the HEX file in via flash programmer thru SmartRF06 evaluation board. I can also single step code via Code Composer Studio V6 and have set break points and single stepped the full FW (most of it). I am using CC1111 USB EVM Kit 868/915 MHz is used to “sniff” packets using the SmartRF™ Protocol Packet Sniffer software as suggested in the design guide. I am also using the PRS file from the downloaded directory. I also see during single stepping that Temp sensor data is OK and 6 byte RF packet (04h, 54h, 63h,78h,6ah, 94h) being formed in memory (as packet buffer) and I can display those in watch window and memory window. All dandy so far.

Now the questions

Problem 1: Not seeing any captured packets on sniffer (except for noise packets with FCS error) if I dont apply filter and if I do apply filter nothing. 
When I single step - after the packer buffer is formed, I see the code issue 

rfHandle = RF_open(&rfObject, &RF_prop, (RF_RadioSetup*)&RF_cmdPropRadioDivSetup, &rfParams);

(This call completes but, I have not checked all status - but as you know, FW code does not test for any return status) - But I see rfHandle etc getting populated)

and then set frequency call

RF_postCmd(rfHandle, (RF_Op*)&RF_cmdFs, RF_PriorityNormal, NULL, NULL);

(This call also completes but, I have not checked all status - but as you know, FW code does not test for any return status) - I see 0x393 (915Mhz) getting into variable etc.. getting populated)

Then it issues:

RF_Event result = RF_runCmd(rfHandle, (RF_Op*)&RF_cmdPropTx, RF_PriorityNormal, NULL, NULL);
if (result != RF_EventCmdDone)

This call hangs - and of course no packets are sniffed by sniffer. Now.. I also did single step this call and here are my observations:

#1. I see that RF.C file code moves on to: RF_CmdHandle RF_postCmd(RF_Handle h, RF_Op* pOp, RF_Priority ePri, RF_Callback pCb, RF_EventMask bmEvent) 

and tries to post this command (as if the previous ones are not complete for whatever reason) and eventually the code moves to:

// Command has still not finished, override callback with one that posts to semaphore and will go to:

// Wait for semaphore
Semaphore_pend(Semaphore_handle(&h->state.semSync), BIOS_WAIT_FOREVER);

And will NOT come back from here... 

Observation1: Seems to me that, Radio processor is not processing commands anymore and the queue gets filled (I also see ch number getting from 0 up to 2 during single stepping / break point debug). I have both 32khz and 24Mhz crystals mounted but have NOT checked radio. I checked VDDR abd it measures 1.682 volts which is pretty close to 1.7 min that CC1310 data sheet evangelizes.

Observation2: I tried to use RF studio to command the TIDA target board to operate radio (via XDS 100v3 and 10 pin ribbon cable path) and I see commands line TXMIT, FS etc.. printing IDLE as status except for Abort command that prints status OK. So, seems radio is not working

Any help is appreciated. Thanks in advance.

Sham Datta.

  • Can you please look at the status of the different commands when stepping through the code?

    RF_cmdPropRadioDivSetup.status

    RF_cmdFs.status

    RF_cmdPropTx.status

    this might give you an indication as to what goes wrong

    Siri

  • Thanks, Siri - for quick reply. Will try this soon and keep you all posted.

    Sham

  • Siri,

    Here are the TEST RUN results in detail (Please see attached TEXT file). I have inserted my comments in the text file itself to explain or record my humble observations. If you cannot read my file (for some reason), let me know and I can find some other way to send the data. 

    Please take a look and suggest me next steps to root-cause this issue. 

    Thanks in advance,

    Sham Datta.

    ShamsRFCmdStatus_05-16-2020_ver0.txt
    Run #1 - 5/16/2020
    In Memory RF Command status Data
    Remarks:
    
    In this "Run" - I will run each command as Full "StepOver command" and then watch for status structure before and after the CALL.
    
    //______________ After call 	
    	RF_Params_init(&rfParams);	/* Init Radio parameters */
    
    RF_prop
     (address: 2000140c)
    
    0x00	0x00	0x00	0x00	0x71	0x54	0x00	0x00	0x00	0x00	0x00	0x00	0x00	0x00	0x00
    
    RF_cmdPropRadioDivSetup (0x20001620): Command # 3807h - Status shows 0
    
    0x07	0x38	0x00	0x00	0x00	0x00	0x00	0x00	0x00	0x00	0x00	0x00	0x00	0x01	0xF1
    0x02	0x0F	0x00	0x80	0x00	0x24	0x04	0xA0	0x00	0x08	0x00	0xC3	0x10	0xB4	0x14
    0x00	0x20	0x93	0x03	0x00	0x80	0x05	0x00	0x00	0x00
    
    RF_cmdFs call: (Command # 0x0803)
    
    0x03	0x08	0x00	0x00	0x00	0x00	0x00	0x00	0x00	0x00	0x00	0x00	0x00	0x01	0x93
    0x03	0x00	0x00	0x00	0x00	0x00	0x00	0x00	0x00
    
    
    RF_cmdPropTx (Command # 0x3801)
    
    
    0x01	0x38	0x00	0x00	0x00	0x00	0x00	0x00	0x00	0x00	0x00	0x00	0x00	0x01	0x18
    0x1E	0x91	0xD3	0x91	0xD3	0x00	0x00	0x00	0x00
    
    
    RF_cmdTxTest (Command # 0x0808) - I just captured it but I dont this we use this call in TIDA default FW (unless we change it add this call - which I have not)
    
    0x08	0x08	0x00	0x00	0x00	0x00	0x00	0x00	0x00	0x00	0x00	0x00	0x00	0x01	0x08
    0x00	0xCD	0xAB	0x00	0x01	0x91	0xD3	0x91	0xD3	0x00	0x00	0x00	0x00
    
    
    //_________________After call 	---	/* Request access to the radio */
    	rfHandle = RF_open(&rfObject, &RF_prop, (RF_RadioSetup*)&RF_cmdPropRadioDivSetup, &rfParams);
    
    RF_prop
    
    
    0x00	0x00	0x00	0x00	0x71	0x54	0x00	0x00	0x00	0x00	0x00	0x00	0x00	0x00	0x00
    0x00
    
    RF_cmdFs
    
    0x03	0x08	0x00	0x00	0x00	0x00	0x00	0x00	0x00	0x00	0x00	0x00	0x00	0x01	0x93
    0x03	0x00	0x00	0x00	0x00	0x00	0x00	0x00	0x00
    
    
    RF_cmdPropTx
    
    
    0x01	0x38	0x00	0x00	0x00	0x00	0x00	0x00	0x00	0x00	0x00	0x00	0x82	0x01	0x18 
    0x06	0x91	0xD3	0x91	0xD3	0xE8	0x11	0x00	0x20
    
    (Sham's comments: I see packet size is changed to 0x6)
    
    RF_cmdPropRadioDivSetup
    
    
    0x07	0x38	0x00	0x00	0x00	0x00	0x00	0x00	0x00	0x00	0x00	0x00	0x00	0x01	0xF1
    0x02	0x0F	0x00	0x80	0x00	0x24	0x04	0xA0	0x00	0x08	0x00	0xC3	0x10	0xB4	0x14
    0x00	0x20	0x93	0x03	0x00	0x80	0x05	0x00	0x00	0x00
    
    
    //________________________________
    
    
    //______________ After call 	(Executed as full function Step Over)
    /* Set the frequency */
    	RF_postCmd(rfHandle, (RF_Op*)&RF_cmdFs, RF_PriorityNormal, NULL, NULL);
    
    RF_prop
    
    0x00	0x00	0x00	0x00	0x71	0x54	0x00	0x00	0x00	0x00	0x00	0x00	0x00	0x00	0x00
    0x00
    
    
    RF_cmdFs
    
    0x03	0x08	0x00	0x00	0x00	0x00	0x00	0x00	0x00	0x00	0x00	0x00	0x00	0x01	0x93
    0x03	0x00	0x00	0x00	0x00	0x00	0x00	0x00	0x00
    
    (Sham's comments: I see frequency has been at 0x393 = 915 MHz)
    
    RF_cmdPropTx
    
    0x01	0x38	0x00	0x00	0x00	0x00	0x00	0x00	0x00	0x00	0x00	0x00	0x82	0x01	0x18
    0x06	0x91	0xD3	0x91	0xD3	0xE8	0x11	0x00	0x20
    
    
    
    RF_cmdPropRadioDivSetup
    
    
    0x07	0x38	0x00	0x00	0x00	0x00	0x00	0x00	0x00	0x00	0x00	0x00	0x00	0x01	0xF1
    0x02	0x0F	0x00	0x80	0x00	0x24	0x04	0xA0	0x00	0x08	0x00	0xC3	0x10	0xB4	0x14
    0x00	0x20	0x93	0x03	0x00	0x80	0x05	0x00	0x00	0x00
    
    (Sham's comments: I see frequency has been at 0x393 = 915 MHz and power at 1db (same as I see in TIDA source)
    
    //_________________
    After Call: Last Call was executed with single step and finally stopped with a HALT (only sometime I can halt it)
    
    RF_Event result = RF_runCmd(rfHandle, (RF_Op*)&RF_cmdPropTx, RF_PriorityNormal, NULL, NULL);
    	if (result != RF_EventCmdDone)
    
    (This is the call that hangs if we do "Step Over" - sometime we can stop it (not always). So, I move thru this
    carefully - some single steps and some "step overs - like HW_reg calls to write HW registers)
    
    RF_prop
    
    0x00	0x00	0x00	0x00	0x71	0x54	0x00	0x00	0x00	0x00	0x00	0x00	0x00	0x00	0x00
    0x00
    
    RF_cmdFs
    
    0x03	0x08	0x00	0x00	0x00	0x00	0x00	0x00	0x00	0x00	0x00	0x00	0x00	0x01	0x93
    0x03	0x00	0x00	0x00	0x00	0x00	0x00	0x00	0x00
    
    (Sham's comments: I see this call state is OK)
    
    RF_cmdPropTx
    
    
    0x01	0x38	0x00	0x00	0x00	0x00	0x00	0x00	0x84	0x52	0x01	0x00	0x82	0x01	0x18
    0x06	0x91	0xD3	0x91	0xD3	0xE8	0x11	0x00	0x20
    
    (Sham's comments: I see this call state is OK)
    
    //----------
    With Break Point -- Call ---- STUFF HAS CHANGED 0000 7:00pm Version -- Sham
    
    RF_cmdPropRadioDivSetup (After Call here)
    
    
    0x07	0x38	0x02	0x00	0xA4	0x11	0x00	0x20	0x00	0x00	0x00	0x00	0x00	0x00	0xF1
    0x02	0x0F	0x00	0x80	0x00	0x24	0x04	0xA0	0x00	0x08	0x00	0xC3	0x10	0xB4	0x14
    0x00	0x20	0x93	0x03	0x00	0x80	0x05	0x00	0x00	0x00
    
    
    Has chenged compared to before call: (Below)
    
    RF_cmdPropRadioDivSetup
    
    
    0x07	0x38	0x00	0x00	0x00	0x00	0x00	0x00	0x00	0x00	0x00	0x00	0x00	0x01	0xF1
    0x02	0x0F	0x00	0x80	0x00	0x24	0x04	0xA0	0x00	0x08	0x00	0xC3	0x10	0xB4	0x14
    0x00	0x20	0x93	0x03	0x00	0x80	0x05	0x00	0x00	0x00
    
    
    Observations on CHANGES #1:
    Status Has changed to: 0x0002 ---(Do not know what this means)?
    *pnextOp changed to: 0x00000000_200011A4
    0xA4	0x11	0x00	0x20	0x00	0x00	0x00	0x00
    
    When I dump that mem locations - It says: 
    0x2000_11A4 is opRatSync
    opRatSync
    
    0x0A	0x08	0x00	0x00	0x00	0x00	0x00	0x00	0x00	0x00	0x00	0x00	0x00	0x01	0x00
    0x00	0x00	0x00	0x00	0x00
    
    
    Start Time: 0x000F_02F1
    
    //_______________________
    
    Observations on CHANGES #2 (This is second change, I see):
    
    RF_cmdPropTx (Before last Call here - for reference)
    
    RF_cmdPropTx
    
    
    0x01	0x38	0x00	0x00	0x00	0x00	0x00	0x00	0x6C	0x54	0x01	0x00	0x82	0x01	0x18
    0x06	0x91	0xD3	0x91	0xD3	0xE8	0x11	0x00	0x20
    
    RF_cmdPropTx (After Call, I mean hang and forced HALT See Below)
    
    RF_cmdPropTx
    
    
    0x01	0x38	0x00	0x00	0x00	0x00	0x00	0x00	0x84	0x52	0x01	0x00	0x82	0x01	0x18
    0x06	0x91	0xD3	0x91	0xD3	0xE8	0x11	0x00	0x20
    
    Following changes have occurred:
    
    Trigger Number ( Old 84h new 0x6C) , past trigger (52 old - New 54) 
    
    //_____________________________
    
    FINAL WORDS:
    
    As I mentioned, it is hard to stop it when it hangs and one of these times, I also
    got clean "status for following RF_cmdPropRadioDivSetup structre in memory.
    
    
    RF_cmdPropRadioDivSetup
    
    
    0x07	0x38	0x00	0x00	0x00	0x00	0x00	0x00	0x00	0x00	0x00	0x00	0x00	0x01	0xF1
    0x02	0x0F	0x00	0x80	0x00	0x24	0x04	0xA0	0x00	0x08	0x00	0xC3	0x10	0xB4	0x14
    0x00	0x20	0x93	0x03	0x00	0x80	0x05	0x00	0x00	0x00
    
    It has changes in wierd way but no, status error though.
    
    Thanks in advance,
    Sham Datta
    
    
    

  • Siri,

    Here are the TEST RUN results in detail (Please see attached TEXT file). I have inserted my comments in the text file itself to explain or record my humble observations. If you cannot read my file (for some reason), let me know and I can find some other way to send the data. 

    Please take a look and suggest me next steps to root-cause this issue. 

    Thanks in advance,

    Sham Datta

    8524.ShamsRFCmdStatus_05-16-2020_ver0.txt
    Run #1 - 5/16/2020
    In Memory RF Command status Data
    Remarks:
    
    In this "Run" - I will run each command as Full "StepOver command" and then watch for status structure before and after the CALL.
    
    //______________ After call 	
    	RF_Params_init(&rfParams);	/* Init Radio parameters */
    
    RF_prop
     (address: 2000140c)
    
    0x00	0x00	0x00	0x00	0x71	0x54	0x00	0x00	0x00	0x00	0x00	0x00	0x00	0x00	0x00
    
    RF_cmdPropRadioDivSetup (0x20001620): Command # 3807h - Status shows 0
    
    0x07	0x38	0x00	0x00	0x00	0x00	0x00	0x00	0x00	0x00	0x00	0x00	0x00	0x01	0xF1
    0x02	0x0F	0x00	0x80	0x00	0x24	0x04	0xA0	0x00	0x08	0x00	0xC3	0x10	0xB4	0x14
    0x00	0x20	0x93	0x03	0x00	0x80	0x05	0x00	0x00	0x00
    
    RF_cmdFs call: (Command # 0x0803)
    
    0x03	0x08	0x00	0x00	0x00	0x00	0x00	0x00	0x00	0x00	0x00	0x00	0x00	0x01	0x93
    0x03	0x00	0x00	0x00	0x00	0x00	0x00	0x00	0x00
    
    
    RF_cmdPropTx (Command # 0x3801)
    
    
    0x01	0x38	0x00	0x00	0x00	0x00	0x00	0x00	0x00	0x00	0x00	0x00	0x00	0x01	0x18
    0x1E	0x91	0xD3	0x91	0xD3	0x00	0x00	0x00	0x00
    
    
    RF_cmdTxTest (Command # 0x0808) - I just captured it but I dont this we use this call in TIDA default FW (unless we change it add this call - which I have not)
    
    0x08	0x08	0x00	0x00	0x00	0x00	0x00	0x00	0x00	0x00	0x00	0x00	0x00	0x01	0x08
    0x00	0xCD	0xAB	0x00	0x01	0x91	0xD3	0x91	0xD3	0x00	0x00	0x00	0x00
    
    
    //_________________After call 	---	/* Request access to the radio */
    	rfHandle = RF_open(&rfObject, &RF_prop, (RF_RadioSetup*)&RF_cmdPropRadioDivSetup, &rfParams);
    
    RF_prop
    
    
    0x00	0x00	0x00	0x00	0x71	0x54	0x00	0x00	0x00	0x00	0x00	0x00	0x00	0x00	0x00
    0x00
    
    RF_cmdFs
    
    0x03	0x08	0x00	0x00	0x00	0x00	0x00	0x00	0x00	0x00	0x00	0x00	0x00	0x01	0x93
    0x03	0x00	0x00	0x00	0x00	0x00	0x00	0x00	0x00
    
    
    RF_cmdPropTx
    
    
    0x01	0x38	0x00	0x00	0x00	0x00	0x00	0x00	0x00	0x00	0x00	0x00	0x82	0x01	0x18 
    0x06	0x91	0xD3	0x91	0xD3	0xE8	0x11	0x00	0x20
    
    (Sham's comments: I see packet size is changed to 0x6)
    
    RF_cmdPropRadioDivSetup
    
    
    0x07	0x38	0x00	0x00	0x00	0x00	0x00	0x00	0x00	0x00	0x00	0x00	0x00	0x01	0xF1
    0x02	0x0F	0x00	0x80	0x00	0x24	0x04	0xA0	0x00	0x08	0x00	0xC3	0x10	0xB4	0x14
    0x00	0x20	0x93	0x03	0x00	0x80	0x05	0x00	0x00	0x00
    
    
    //________________________________
    
    
    //______________ After call 	(Executed as full function Step Over)
    /* Set the frequency */
    	RF_postCmd(rfHandle, (RF_Op*)&RF_cmdFs, RF_PriorityNormal, NULL, NULL);
    
    RF_prop
    
    0x00	0x00	0x00	0x00	0x71	0x54	0x00	0x00	0x00	0x00	0x00	0x00	0x00	0x00	0x00
    0x00
    
    
    RF_cmdFs
    
    0x03	0x08	0x00	0x00	0x00	0x00	0x00	0x00	0x00	0x00	0x00	0x00	0x00	0x01	0x93
    0x03	0x00	0x00	0x00	0x00	0x00	0x00	0x00	0x00
    
    (Sham's comments: I see frequency has been at 0x393 = 915 MHz)
    
    RF_cmdPropTx
    
    0x01	0x38	0x00	0x00	0x00	0x00	0x00	0x00	0x00	0x00	0x00	0x00	0x82	0x01	0x18
    0x06	0x91	0xD3	0x91	0xD3	0xE8	0x11	0x00	0x20
    
    
    
    RF_cmdPropRadioDivSetup
    
    
    0x07	0x38	0x00	0x00	0x00	0x00	0x00	0x00	0x00	0x00	0x00	0x00	0x00	0x01	0xF1
    0x02	0x0F	0x00	0x80	0x00	0x24	0x04	0xA0	0x00	0x08	0x00	0xC3	0x10	0xB4	0x14
    0x00	0x20	0x93	0x03	0x00	0x80	0x05	0x00	0x00	0x00
    
    (Sham's comments: I see frequency has been at 0x393 = 915 MHz and power at 1db (same as I see in TIDA source)
    
    //_________________
    After Call: Last Call was executed with single step and finally stopped with a HALT (only sometime I can halt it)
    
    RF_Event result = RF_runCmd(rfHandle, (RF_Op*)&RF_cmdPropTx, RF_PriorityNormal, NULL, NULL);
    	if (result != RF_EventCmdDone)
    
    (This is the call that hangs if we do "Step Over" - sometime we can stop it (not always). So, I move thru this
    carefully - some single steps and some "step overs - like HW_reg calls to write HW registers)
    
    RF_prop
    
    0x00	0x00	0x00	0x00	0x71	0x54	0x00	0x00	0x00	0x00	0x00	0x00	0x00	0x00	0x00
    0x00
    
    RF_cmdFs
    
    0x03	0x08	0x00	0x00	0x00	0x00	0x00	0x00	0x00	0x00	0x00	0x00	0x00	0x01	0x93
    0x03	0x00	0x00	0x00	0x00	0x00	0x00	0x00	0x00
    
    (Sham's comments: I see this call state is OK)
    
    RF_cmdPropTx
    
    
    0x01	0x38	0x00	0x00	0x00	0x00	0x00	0x00	0x84	0x52	0x01	0x00	0x82	0x01	0x18
    0x06	0x91	0xD3	0x91	0xD3	0xE8	0x11	0x00	0x20
    
    (Sham's comments: I see this call state is OK)
    
    //----------
    With Break Point -- Call ---- STUFF HAS CHANGED 0000 7:00pm Version -- Sham
    
    RF_cmdPropRadioDivSetup (After Call here)
    
    
    0x07	0x38	0x02	0x00	0xA4	0x11	0x00	0x20	0x00	0x00	0x00	0x00	0x00	0x00	0xF1
    0x02	0x0F	0x00	0x80	0x00	0x24	0x04	0xA0	0x00	0x08	0x00	0xC3	0x10	0xB4	0x14
    0x00	0x20	0x93	0x03	0x00	0x80	0x05	0x00	0x00	0x00
    
    
    Has chenged compared to before call: (Below)
    
    RF_cmdPropRadioDivSetup
    
    
    0x07	0x38	0x00	0x00	0x00	0x00	0x00	0x00	0x00	0x00	0x00	0x00	0x00	0x01	0xF1
    0x02	0x0F	0x00	0x80	0x00	0x24	0x04	0xA0	0x00	0x08	0x00	0xC3	0x10	0xB4	0x14
    0x00	0x20	0x93	0x03	0x00	0x80	0x05	0x00	0x00	0x00
    
    
    Observations on CHANGES #1:
    Status Has changed to: 0x0002 ---(Do not know what this means)?
    *pnextOp changed to: 0x00000000_200011A4
    0xA4	0x11	0x00	0x20	0x00	0x00	0x00	0x00
    
    When I dump that mem locations - It says: 
    0x2000_11A4 is opRatSync
    opRatSync
    
    0x0A	0x08	0x00	0x00	0x00	0x00	0x00	0x00	0x00	0x00	0x00	0x00	0x00	0x01	0x00
    0x00	0x00	0x00	0x00	0x00
    
    
    Start Time: 0x000F_02F1
    
    //_______________________
    
    Observations on CHANGES #2 (This is second change, I see):
    
    RF_cmdPropTx (Before last Call here - for reference)
    
    RF_cmdPropTx
    
    
    0x01	0x38	0x00	0x00	0x00	0x00	0x00	0x00	0x6C	0x54	0x01	0x00	0x82	0x01	0x18
    0x06	0x91	0xD3	0x91	0xD3	0xE8	0x11	0x00	0x20
    
    RF_cmdPropTx (After Call, I mean hang and forced HALT See Below)
    
    RF_cmdPropTx
    
    
    0x01	0x38	0x00	0x00	0x00	0x00	0x00	0x00	0x84	0x52	0x01	0x00	0x82	0x01	0x18
    0x06	0x91	0xD3	0x91	0xD3	0xE8	0x11	0x00	0x20
    
    Following changes have occurred:
    
    Trigger Number ( Old 84h new 0x6C) , past trigger (52 old - New 54) 
    
    //_____________________________
    
    FINAL WORDS:
    
    As I mentioned, it is hard to stop it when it hangs and one of these times, I also
    got clean "status for following RF_cmdPropRadioDivSetup structre in memory.
    
    
    RF_cmdPropRadioDivSetup
    
    
    0x07	0x38	0x00	0x00	0x00	0x00	0x00	0x00	0x00	0x00	0x00	0x00	0x00	0x01	0xF1
    0x02	0x0F	0x00	0x80	0x00	0x24	0x04	0xA0	0x00	0x08	0x00	0xC3	0x10	0xB4	0x14
    0x00	0x20	0x93	0x03	0x00	0x80	0x05	0x00	0x00	0x00
    
    It has changes in wierd way but no, status error though.
    
    Thanks in advance,
    Sham Datta
    
    
    

  • I am afraid I did not understand everything regarding what you were displaying in the log. what I simply was after, was to look at the status.

    The code for this design is VERY old and do not uses our SDKs. Unfortunately I was not able to even get the code to build.

    What I want you to do is to comment away the code that has to do with the sensors and simply just test the radio. You should modify your txTaskFunction to just send a dummy packet. If the radio is OK you will see that the setup command and TX command have status 0x3400 (PROP_DONE_OK) and that the FS command has status 0x0400 (DONE_OK).

    I was running the same radio code with our newest SDK, and then I was stuck in the while loop after the packet was sent the first time:

    The reason is that the radio reports RF_EventLastCmdDone and not RF_EventCmdDone.

    If the radio part of the code run as it should, but you are still not able to receive any of the packets you are sening, I would suspect that the problem could be RF related (have you made the boards yourselves?, have you more boards you could test?, have you followed the reference design closely?)

    Siri

  • Siri,

    Thanks for quick responses. Let me comment on each of the items you have brought up, so that you can help me better.

    #1. You mention the code for design is very old (and you could not build it). 

    Question #1: Would it possible for you to just take the HEX file (from TIDA-00484 rev3 design) and run the radio section on your SDK environment. The reason, I am asking for this is to just make sure that "All the radio library code underneath in the OLD TIDA design is all still solid and no improvement or robustness to that is suggested". 

    By looking at the Radio code snippet you sent me, it is exactly same as TIDA main.c source, except for the last Send Packet call processes the result as "RF_eventMask result" instead of "RF_Event result ". So, the code is same (but underlying radio library code in your SDK could all be newer). IMHO, this shall hardly make any difference - since on my setup / board this call never comes back.

    Is not it correct that, I am still basically testing RADIO in my setup also, since on each RUN - the packet build ok (In other words sensor code is reading it all ok).

    I will run my code again (with everything else taken out) and will check for status 0x3400 and 0x400. Will keep you posted on this one.

    Question #2: In my setup, as I mentioned earlier - "smart RF06EB" board  is driving my TIDA card 10 pin JTAG as design guide suggested. In this setup, can ONE still use RF06EB device control panel to send packets and test radio (I mean this PC program will command CC1310 via JTAG to operate radio) - Or this setup will NOT work for testing radio? What I mean that, smart RF06EB can only just drive JTAG for CCS debug but cannot operate CC1310 via JTAG? Since I am seeing IDLE status there after SEND packet -- I would like to know, since this is ANOTHER METHOD to test my board radio instead of flash code on the board.

    Question #3: 

    The current board I am testing was done exactly by taking in "all the PCB Altium files doled out on the web freely by TI". So, it is an exact clone. I want to get this running and add more sensors to this via GPIO / I2C (add code support for them) and then make enhanced board for my application once I have cleared all hurdles with reference board HW and code. So, at the end of the day board is a clone - but I can do more HW debug (the board was done by a local PCB service here in Oregon).

    I will invest time on more HW debug after I do all code debug (as you have suggested). 

    But since RADIO is all contained on TI chip - my thought was that code shall run to completion, even though packer sniffer may not detect it (due to RF side HW). Is not this correct? Or do you think, unless all the RF side HW (coils, caps and antenna) are dandy TX code can hang. My thought it would still pump data out on TX pins and give me status OK (Is not this correct?) as long RF CLOCK and power and such basic stuff was OK (like VDDR at 1.7v etc).

    Thanks again. Let me know your thoughts on these. I will continue code debug a bit more on my side and will keep you posted.

    Sham

  • Hi

    #1:

    I cannot see how I can test anything doing this. I do not have the needed HW, so I guess that as soon as the code tries to read any of the sensors (which is not there), there will be problems.

    #2:

    You can try to download SmartRF Studio on you PC and see if you are able to get contact with the CC1310 this way.

    #3:

    On the receiving side, it might be a good idea to use SmartRF Studio in cont. RX. There you might be able to confirm that your board is transmitting packets, even if you are not able to receive them correctly (you will see that there is a signal on the air)

    BR

    Siri

  • Siri,

    Just clarifying further, so that you can help me better.

    #1. Siri > I cannot see how I can test anything doing this. I do not have the needed HW, so I guess that as soon as the code tries to read any of the sensors (which is not there), there will be problems

    Sham> I understand that part. Some clarifications on my ask. I know (from your last post) that you did RUN on your SDK almost exactly the same TIDA 00484 "radio command sequence" that TIDA 00484 has in it's source and it completed from RADIO SW point of view. What I wanted to know was: When you ran TIDA-00484 higher level "radio send command sequence" - is the underlying radio code library "like rf.c and much more" in your SDK environment same?  In other words, I was thinking - is he low level radio code in your SDK environment was different than TIDA 00484 source library that I am using. 

     

    #2: On 2:

    Siri> You can try to download SmartRF Studio on you PC and see if you are able to get contact with the CC1310 this way

    Sham> I did do this. Like I said in one of my lengthy emails - the SmartRF studio reports "IDLE" as status for every command in sending sequence (Divsetup, FS and Txdata). But NOT sure if it is successfully talking to RF RAM on chip via 10 pin JTAG and doing this. I was asking this question, because - TIDA documentation evangelized using RfStudio as a method of talking to TIDA 00484 to do FLASH programming and nothing more than that.  So, I am NOT sure if anyone used SmartRF via JTAG to test CC1310 radio. Let me know, if that path of testing is supposed to work. Even SmartRF06 manual ONLY talks about RF debug and evaluation of BOARDs plugged as evaluation modules into SmartRF06 but NOT via JTAG

    I even suggest / request TI - that, if JTAG path to do RF testing works - it would be very helpful to developers to have a section on it and specifically explain JTAG path to do Radio debug.

    #3: On 3:

    Siri > On the receiving side, it might be a good idea to use SmartRF Studio in cont. RX. There you might be able to confirm that your board is transmitting packets, even if you are not able to receive them correctly (you will see that there is a signal on the air)

    Sham> Have a question on that:  My understanding is that: if I configure SmartRF studio in cont. RX - it basically configures CC1310 on TIDA 00484 to "Cont. RX mode" (provided it can do it via JTAG).  So... is the following assertion correct then?

    (a) If I configure this way, then SmartRF06 will configure CC1310 located on TIDA-00484 to do both "Transmit and Receive packets". I am asking this because my thinking is SmartEF06 board itself does NOT have any Radio chip (as far as I understand from it's documentation). Anyway - let me try this and then ask more questions.

  • #1)

    Probably not. The TI design is made with TI-RTOS 2.14.03.28 which is from 2015, and I did a test with the newest simplelink_cc13x0_sdk_4_10_00_10. I would guess that there have been done many changes/improvements to the RF driver since then.

    #2)

    I am not sure I understand. It is not possible to use SmartRF Studio to do any flash programming. For that, you would use the SmartRF FlashProgrammer.

    I just took a SmartRF06EB and used the 10 pin ARM Cortex Debug Connecter to my CC1310LP. I was then able to run PacketTX from Studio, verifying that the CC1310 on my external board (in my case, the LP) worked as it should. Transmitting 1 packet from Studio, would cause the following 4 commands to be executed:

     >CMD_PROP_RADIO_DIV_SETUP executed

    > Status: 0x3400 DONE_OK

    >CMD_FS executed

    > Status: 0x400 DONE_OK

    >CMD_PROP_TX executed

    > Status: 0x3400 DONE_OK

    >CMD_ABORT executed

    > Status: 0x1 DONE_OK

    #3)

    You should be able to transmit and receive from Studio as described under #2).

    Siri

  • Siri,

    First of all, excellent support. Thank you very much for all the answers to my long questions. Appreciate it. See my comments / questions below, in this COLOR

    Siri >> #1)

    Probably not. The TI design is made with TI-RTOS 2.14.03.28 which is from 2015, and I did a test with the newest simplelink_cc13x0_sdk_4_10_00_10. I would guess that there have been done many changes/improvements to the RF driver since then.

    Sham> OK. I understand. I may try the new code (if it compiles easily and I know, it may not) to just see if it gives me any more insights. As you may already know, I am trying to root-cause the issue (HW or FW) -- so that I can fix all that in my next custom board with CC1310 - so that it will be stable for production.

    #2)

    Siri >> I am not sure I understand. It is not possible to use SmartRF Studio to do any flash programming. For that, you would use the SmartRF FlashProgrammer.

    Sham> Oh.. I was not too clear. Of course. I did use SMARTRF Flash programmer SW. It successfully talked thru SmartRF06 board's 10 pin ARM Cortex JTAG into TIDA - 00484 board resident CC1310's flash controller. FYI, flash erasure, programming, verification - all worked OK

    Siri >> I just took a SmartRF06EB and used the 10 pin ARM Cortex Debug Connecter to my CC1310LP. I was then able to run PacketTX from Studio, verifying that the CC1310 on my external board (in my case, the LP) worked as it should. Transmitting 1 packet from Studio, would cause the following 4 commands to be executed:

    Sham>> That proves that, SmartRF06EB is able to download commands into RF RAM and run the RF controller. Thanks. I know, it is NOT working in mine (just like the FW code is not working). I will do MORE DEBUG and keep you posted soon. Again, I suggest / request a NOTE may be placed in next revision of SmartRF06EB manual (XDS100 section) to explicitly tell readers that JTAG path can be used to send RADIO commands shall work fine (Hopefully, it helps developers, reading the manual).

     >CMD_PROP_RADIO_DIV_SETUP executed

    > Status: 0x3400 DONE_OK

    Sham>> As of now I get Status: IDLE (On screen). Let me debug a bit more here.

    >CMD_FS executed

    > Status: 0x400 DONE_OK

    Sham>> Same as above. As of now I get Status: IDLE (On screen). Let me debug a bit more here.

    >CMD_PROP_TX executed

    > Status: 0x3400 DONE_OK

    Sham>> Same as above. As of now I get Status: IDLE (On screen). Let me debug a bit more here.

    >CMD_ABORT executed

    > Status: 0x1 DONE_OK

    Sham>> Surprising this command reports Stats OK (I think) - Let me run more debug on these.

    #3)

    You should be able to transmit and receive from Studio as described under #2).

    Siri

  • It might be useful if you can post a screenshot of SmartRF Studio after you have tried to run PacketTX from Studio with your board connected. Make sure that you show all the Output messages.

    Siri

  • Siri, Hi

    Experiment #1: Here it is (Please see below) - The screen shot from SmarRFStudio. 

    Experiment #2:

    Also, I found that status of command: RF_cmdPropRadioDivSetup.status changes from 0x00 to 0x02 (after the code executes the last call is executed (from which it does not return)). It remains at 0x0 when setup and RF_CMDFs executed and then changes 0x2h.

    Let me know, what 02h status for RF_cmdPropRadioDivSetup.status means

    Sham

    //____________ 

    The screen shot from SmarRFStudio is pasted below:

  • Sending Screen shot as a file.

  • Siri,

    Hello, again. I did more debug. Checked all my tools setup using CC1310 launch pad. All that worked ok. Eventually, I strongly suspected this (based on all the debug input) as a HW issue and CC1310 chip probably not getting a good 24 MHz i/p clock from crystal. 

    Took it to a local PCB shop and had the PCB inspected and they found that indeed 24 Mhz crystal package was reversed (not mounted correctly). Once, I got this fixed - the board is working fine and I am on my way to modify the circuit adding more sensors and customizing it to our requirements.

    Again, thanks for all the support. I am marking the issue resolved.

    Regards,

    Sham