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.

CC2530: CC2530 & BasicRF RX and TX hangs out

Part Number: CC2530
Other Parts Discussed in Thread: CC2591, , TIMAC, SIMPLICITI, CC1352P, CC2652P

Hi everyone,

I am using CC2530 + CC2591 and BasicRF (from the CC2530 examples) to comunicate 3 devices. The RF setup is simple: broadcast messages between the three without ACK and the radio (RX) is ON always. Two of these devices can run alone (Device 1 and 2), but in a specific condition they have to syncronize. The way how the are sync is very easy, the device 1 sends a packet, the second receives this packet and sends its own, then the device 1 receives it and so on. Seding period between device 1 and 2 is 70ms. The time between packet reception and transmition is just few miliseconds (I use Osal Timers from Zstack). 

I had/have two specific problems in 2 scenarios:

SCENARIO 1:

Device 1 and 2 when are comunicating (sync. or not sync) : TX of device 1 or 2 hang out after transmitting and receiveng for 5 - 10 minutes. The problem is in the function "halRfTransmit()", specifically in the instruction "while (!(RFIRQF1 & IRQ_TXDONE));" The result of this logic AND is always 0, so the IRQ flag is never cleared. I read some discussion in the forum but there is not any solution... But in this case I implemented a workaround which consist in enabling the RFERR interrupts due to over/underflow radio and setting the RFIRQF0 = 0;  RFIRQF1 = 0; RFERRF = 0; and S1CON = 0; This workaround seems run OK until now.

My question here is if this is the correct way to fix the problem or if there are another better. Has anybody has the same problem? 

SCENARIO 2:

Device 1 and 2 when are comunicating (sync. TX and RX)  and the third only sends packets (receive mode is OFF): RX of device 1 or 2 hang out after transmitting and receiveng sync packets and receiveing packets from the third for ~5. The problem here is the RX interrupt never is trigered, so the function "basicRfPacketIsReady()" returns always FALSE. The only way to recover the communication is performing a reset of the device 1 or 2. Here seems that the problem is RX FIFO is under or overflowed. I monitorize the RFERR register and I try to use the same workaround but it doesn't work. The RX radio is completely hang out. Even I initialize again the radio configuration with the function "basicRfInit(basicRfCfg_t* pRfConfig)" but it doesn't work. I tried also to FLUSH the RXFIFO, but without success. Other peripheral like the GPIO, UART or Osal Timers are working well, but the radio is KO. 

My questions are:

1. Any idea about how avoid this problem? Why is radio OFF?

2. Reconfiguring the radio doesn't solve the problem: is there any register to reset the Radio peripheric? I don't want to reset the device...

Thanks.

Joaquim.

  • Hi Joaquim,

    For scenario 1, I think you have implemented a reasonable workaround and am not aware of any better solutions.

    For scenario 2, it is likely that you have encountered a radio error which is not handled by the Basic RF layer.  Section 5.2.5 of the CC2530 Software Examples documentation specifically states that "RX FIFO overflow handling is not implemented, and such an error will cause the software to stall."  This is why TIMAC, SIMPLICITI, or another more complete stack is used for commercial products.  Do you attempt to toggle the radio's interrupt and RX functionality OFF/ON while flushing the RX FIFO?  You can check hal_rf.c for register control from basicRf* APIs.

    Regards,
    Ryan

  • Hi Ryan,

    Thanks for the answer. 
    I will try to turn off the radio before flush the RX FIFO. Which option do you think is better for my application?

    Thanks.

  • What options are you referring to?  If you are attempting to develop a robust and reliable product instead (as compared to radio evaluation) then I would highly recommend considering one of the formal protocol stacks mentioned.  You would also have more resources and further support available if you migrated from the Legacy CC253X platform to a SimpleLink CC26X2 solution.

    Regards,
    Ryan

  • Hi Ryan,

    I was referring to Timac or Simplificty.

    Thanks for the advice to move to CC26x2, in fact I am evaluating CC1352P with TI RTO. But I have to discover the way to make compatible the communication between CC2530 and BasiRF and the CC1352P because the devices has to be fully compatibles. In your opinion CC1352P would be a better solution than the CC26x2?

    I think they are very similar, the main difference is that CC1352P supports 868MHz.

    Joaquim.

  • The CC2652P is the same device as the CC1352P but with the Sub-1 GHz radio removed, I assume the CC2652P would be preferred since the CC2530 only has a 2.4 GHz radio.

    Regards,
    Ryan