CC2538: smart rf TX slower compared to CC2530

johni

Part Number: CC2538
Other Parts Discussed in Thread: CC2530, CC2531

Hi,

I'm doing some TX/RX tests between CC2538 and CC2530.

I've noticed that transmitting with CC2538 is much slower compared to transmitting with CC2530. CC2538 seems to deliver packets with a frequency of ~1 second.

Receiving is not a problem with both CC2538 and CC2530 as if I transmit from CC2530, CC2538 seems to receive packets at the same frequency CC2530 deliver them.

Why CC2538 is slower in TX? That is a huge problem for my application as I'm using CC2538 as coordinator which will also be responsible for upgrading devices via OTA and that will take ages.

Any help would be very much appreciated.

Thanks,

John

over 6 years ago

0 YiKai Chen over 6 years ago

Guru 735455 points

What test do you use to judge CC2538 transmitting slower than CC2530?

0 johni over 6 years ago in reply to YiKai Chen

Intellectual 280 points

Both the packet counter in smartrf and the sniffer log.

0 johni over 6 years ago in reply to johni

Intellectual 280 points

The test I do is transmitting 100 packets from one device to the other.

0 YiKai Chen over 6 years ago in reply to johni

Guru 735455 points

What’s the device type you test this? Router or end device?

0 johni over 6 years ago in reply to YiKai Chen

Intellectual 280 points

My application uses CC2538 as Coordinator and CC2530 as end device. Although for the problem highlighted here doesn't really matter as with SmartRF studio is PER testing.

0 YiKai Chen over 6 years ago in reply to johni

Guru 735455 points

Do you mean you see this issue on PER test?

0 johni over 6 years ago in reply to YiKai Chen

Intellectual 280 points

correct

0 YiKai Chen over 6 years ago in reply to johni

Guru 735455 points

As I know, PER only counts how many packets are received after sending a specific amount of packets and it is not related to RF speed.

0 johni over 6 years ago in reply to YiKai Chen

Intellectual 280 points

But in any case packets are dispatched slowly compared to CC2530. I attached 2 sniffer logs so that will give a better idea of what I'm talking about. One is for packets sent from CC2538 and the other one from CC2530. Sending 100 packets takes around 1.7 mins on CC2538 vs 42 seconds on CC2530.

CC2538_CC2530.zip

0 YiKai Chen over 6 years ago in reply to johni

Guru 735455 points

I suppose these are different timing used for CC2538 and CC2530 in SmartRF Studio 7. We cannot change the TX period in SmartRF Studio 7 so maybe try to revise PER source codes of CC2538 and CC2530 to test it with the same TX period to verify it.

0 johni over 6 years ago in reply to YiKai Chen

Intellectual 280 points

I have the same issue with ZNP (i.e. distributing ota upgrades from CC2538 is slower then using CC2531). Is there a way to change the TX period for CC2538 in ZStack?

0 YiKai Chen over 6 years ago in reply to johni

Guru 735455 points

If I remember correctly, OTA speed is controlled by device polling for image.

0 Jason Cole26 over 6 years ago in reply to YiKai Chen

Intellectual 710 points

Hi guys

I've been looking into this too. I have added some debug trace messages to the ZNP and note some considerable delays from when a transmit (e.g. update ON/OFF) is received in the UART to when it is transmitted on the MAC.

I've worked with systems before that avoid sending short transmissions by accumulating data before commencing a frame transmission. Is there some intermediate process like that which is happening here? Could it be that a NV-RAM write is occurring?

A couple of examples:

CMD_RXD: TS 746689 $24 $2 len 23
(621ms)
MAC_TxS: TS 747310 CSMA 1 FrmeTyp 1 ReTx 0 Len 46: FC 8861 ... SN 249 ... PAN 8ece ... nAddr c6e3

CMD_RXD: TS 797211 $24 $2 len 24
(917ms)
MAC_TxS: TS 798128 CSMA 1 FrmeTyp 1 ReTx 0 Len 47: FC 8861 ... SN 3 ... PAN 8ece ... nAddr c6e3

Where MAC_TxS is at the beginning of "macTxFrame" (mac_tx.c)
and CMD_RXD is at the beginning of "MT_ProcessIncoming" (MT.c)

The timestamps from start to end of "macTxFrame" appear to be within 1ms, so I doubt very much that we are seeing Tx being held off due to CSMA.

What can we do to minimise these delays?

0 Jason Cole26 over 6 years ago in reply to Jason Cole26

Intellectual 710 points

I have added some tracing to AF_DataRequest and can confirm there are no delays from MT_ProcessIncoming() up to the APSDE_DataReq() call:

[14:58:44.544,021]: CMD_RXD: TS 1784983 $25 $1 len 4
[14:58:44.570,761]: AF_DR..: TS 1784983 EP 0 CR 1
[14:58:50.084,459]: MAC_TxS: TS 1790519 CSMA 1 FrmeTyp 1 ReTx 0 Len 45: FC 8841 SN 143 PAN fc50 nAddr ffff
[14:58:50.100,603]: MAC_TxE: TS 1790519 (diff 0)

0 TA12012 over 6 years ago in reply to Jason Cole26

TI__Mastermind 36375 points

I am closing this thread as it has wondered off its original topic. The original topic was about the speed of packet reception using SmartRF studio using CC2530 and CC2538. The reason here is that the devices are very different (8051 core versus ARM-M3 core) and the software/hardware infrastructure between the DUT and SmartRF Studio is very different. We recognize that the 2538 is slower, but there is nothing we can do to improve them today.

Regards,
/TA

Zigbee & Thread

Zigbee & Thread forum

CC2538: smart rf TX slower compared to CC2530