TIDA-00484: Board and FW Debug

Prodigy 140 points

Replies: 13

Views: 97

Part Number: TIDA-00484

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.

13 Replies

  • Guru 50445 points

    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

     

  • In reply to Siri:

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

    Sham

  • In reply to 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.ShamsRFCmdStatus_05-16-2020_ver0.txt

  • In reply to Siri:

    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

  • Guru 50445 points

    In reply to 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

     

  • In reply to 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

  • Guru 50445 points

    In reply to Sham Datta:

    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

     

  • In reply to 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.

  • Guru 50445 points

    In reply to Sham Datta:

    #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

     

  • In reply to 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