RTOS/cc2538: Coordinator UART fails when beacon request is received.

Dan O'Connell

Part Number: CC2538
Other Parts Discussed in Thread: Z-STACK

Tool/software: TI-RTOS

Hi to All,

I use CC2538, Z-Stack Energy, IAR ARM M3.

I have recently discovered a strange problem with our Coordinator UART system: it becomes unresponsive when a device attempts to join the network (sends out a beacon request). I don't want the device to join, so our permit-join is obviously disabled. But several tests have shown consistently that the UART system (for control via a PC) stops responding the moment a device sends beacon requests, and if that device is powered down, our UART system recoveres and works properly again.

Does anyone have any advice?

This could be a serious problem for us, as anyone could come with any device and simply by sending a beacon request, break our network control.

Thanks!

over 6 years ago

0 YiKai Chen over 6 years ago

Guru 735455 points

What is your coordinator based on? Is it ZNP?

0 Dan O'Connell over 6 years ago in reply to YiKai Chen

Genius 3135 points

Hi YiKai,

What do you mean by ZNP? Are you referring to the MT system? We make use of the MT_APP.c file with the MT_APP_FUNC compiler sections, and our application data is processed in the coordinator function called esp_ProcessAppMsg().

0 Dan O'Connell over 6 years ago in reply to Dan O'Connell

Genius 3135 points

(From the functions in Z-Stack that control UARTto-application data, it appears that we do make use of ZNP)

0 YiKai Chen over 6 years ago in reply to Dan O'Connell

Guru 735455 points

I think you don't use ZAP-ZNP architecture. You just enable MT/ZNP command on your coordinator and your coordinator is based on Z-Stack SE example. Am I right?

0 Dan O'Connell over 6 years ago in reply to YiKai Chen

Genius 3135 points

Yes that's correct

0 Dan O'Connell over 6 years ago in reply to Dan O'Connell

Genius 3135 points

Would it be better to use the ZAP-ZNP architecture? What is the link to the beacon request interference?

0 YiKai Chen over 6 years ago in reply to Dan O'Connell

Guru 735455 points

Does any device send beacon requests cause this issue or only specific device cause this trouble?

0 Dan O'Connell over 6 years ago in reply to YiKai Chen

Genius 3135 points

I've just tried 3 other devices, and they all make the UART less responsive, when they send a beacon request with the intention of joining the network.

0 Dan O'Connell over 6 years ago in reply to Dan O'Connell

Genius 3135 points

We have a network of between 7 and 10 devices at any given time. Would the business of all of them communicating have something to do with this?

0 YiKai Chen over 6 years ago in reply to Dan O'Connell

Guru 735455 points

That is what I suspect. Does your application keep coordinator very busy?

0 Dan O'Connell over 6 years ago in reply to YiKai Chen

Genius 3135 points

Our network environment has 18 devices on 4 PANs all on one channel (26). Of that, 10 are on the network in question, and the other 3 PANs have 2-3 devices at any given time.

On the PAN in question, for a 10 second time frame, about 100 packets of all types are sent between the nodes, which means 10 packets /s. Of that, the coordinator receives and sends packets at about 4 packets /s. When a beacon request is broadcast obviously the rates will increase substantially.

Maybe the busyness on Ch26 overloads the coordinator's MAC & NWK task loops?

0 YiKai Chen over 6 years ago in reply to Dan O'Connell

Guru 735455 points

That what I suspect. I suggest you to change a channel or slow down everything to test again.

0 Dan O'Connell over 6 years ago in reply to YiKai Chen

Genius 3135 points

Ok we will try that thanks YiKai

0 Dan O'Connell over 6 years ago in reply to Dan O'Connell

Genius 3135 points

Just another quick question on this issue:

I have fixed the channel to 26. If I instead allowed the coordinator to use its full channel selection (11-26), the coordinators will change their channel when a busy network develops, and this will help in a big way to solve the problem, right??

0 YiKai Chen over 6 years ago in reply to Dan O'Connell

Guru 735455 points

It depends on if the busy traffic cause serious enough interference. If yes, coordinator should switch channel. However, I am not sure if it would solve your issue. You shall move to a more clean channel to see if issue is solved first.

0 Dan O'Connell over 6 years ago in reply to YiKai Chen

Genius 3135 points

Ok thanks YiKai, ill try a few options.

We came up with another possible contributing problem:

Our routers do not stop sending beacon requests when they are attempting to discover a network. Are they not supposed to attempt to join and then if not successful stop transmitting for a time, and then attempt again? The Zigbee base spec from 2016 seems to require this.

Would adjusting NWK_START_DELAY (ZDApp.c) to a value much higher than 100ms make it do this?

0 YiKai Chen over 6 years ago in reply to Dan O'Connell

Guru 735455 points

No, Zigbee spec doesn't specify this new join behavior. You can stop joking from your application if it cannot join for a while.

0 Dan O'Connell over 6 years ago in reply to YiKai Chen

Genius 3135 points

Ok thanks YiKai.

We thought of doing that anyway to lessen the network traffic when a device attempts to join. Maybe 5s join attempt, 30s quiet.

I was thinking of doing this by testing devState for a time, and if not joined then change devState to DEV_HOLD for a time, to keep the device from transmitting anything, then change devState to DEV_NWK_DISC, for a time, etc. (I'll call osal_set_event( ZDAppTaskID, ZDO_STATE_CHANGE_EVT ) as well to make the device apply the changed state.) This should work right?

0 YiKai Chen over 6 years ago in reply to Dan O'Connell

Guru 735455 points

I think you should add a count in ZDO_NETWORK_INIT event to implement this.

0 Dan O'Connell over 6 years ago in reply to YiKai Chen

Genius 3135 points

Ok thanks YiKai, I'll look into this.

Thanks again for all your valuable advice!

Zigbee & Thread

Zigbee & Thread forum

RTOS/cc2538: Coordinator UART fails when beacon request is received.