RTOS/CC1352R: Z-Stack examples not properly working on CC1352R Custom board

I suggest you to use SmartRF Studio to test if RF of your custom board works fine.

Hi Angel,

I have confirmed that the SIMPLELINK-CC13X2-26X2-SDK v3.10 Zigbee examples operate as expected with the LAUNCHXL-CC1352R1 and CC1352R1 Rev E. Can you please debug your project with optimizations off to further determine the state of the MCU? I am not aware of any HW dependencies between this SDK and previous versions but we may loop in the hardware experts if the issue persists.

Regards,
Ryan

Thanks for the reply,

I am sure hardware works, I can sniff packets sent with SmartRF´s Packet TX feature. The main difference is that no UART and external memory are connected, but I think none of these compromise example´s functionality.

Anyway, I have disabled the optimizations but I still have not found a way to figure out what is wrong. I use a software timer to trigger the KEY_LEFT event, so the Zstackapi_bdbStartCommissioningReq() is reached eventually. Stepping in, I can see in the sendReqDefaultRsp() that OsalPort_msgSend() returns a status of SUCCESS. At this point the old SDK and Launchpad with REV C. version starts the commissioning process. There is however not any way to debug further into this. Do you have any other suggestion?

Thanks in advance.

Regards,
Angel

I made a mistake, could you please unmark this as Resolved? I have no idea how to do that and I see no point of creating a new question.

Thanks.

Hello Angel,

We will continue to support this thread even though it is marked as resolved. Zstackapi_bdbStartCommissioningReq -> zstackmsg_CmdIDs_BDB_START_COMMISSIONING_REQ -> processBdbStartCommissioningReq -> bdb_StartCommissioning, so this is your next debug step.

Regards,
Ryan

I suggest you to use sniffer to check if your device sends beacon requests when your application calls bdb_StartCommissioning.

zr_light_CC1352R1_LAUNCHXL_tirtos_ccs_hex.txtHi Ryan,

I followed your advice and debugged the Commissioning process further. I could verify it reaches the ZDOInitDeviceEx() on both working and non-working setups. Same status and modes are seen, the only difference is that no m essages are sent over the air with the Rev. E board.

I can only think on sending my HEX file and kindly ask you to test on a Rev. E Launchpad. It should start sending beacons after ca. 3 seconds of power up and repeatedly every 5 seconds. Again, the custom board works flawlessly using SmartRF Studio to send packets. If this works on the Launchpad, then the issue could be isolated to be a hardware configuration problem.

Regards,

Angel

Hi Angel,

That's a great idea, I can confirm that beacon requests are sent OTA with the firmware image you've provided so I agree that something appears to be wrong with the hardware configuration. You may be required to share schematics and a board layout at this point.

Regards,
Ryan

Hello,

For the moment I cannot share the layout files, but I am using the 0900PC15A0036 Balun from Johanson Technology as discussed in swra629 application note. The Packet RX and TX using Smart RF studio proves that the hardware works properly. Random packets are seen by sniffer and ZigBee Beacons form external devices are seen when in RX mode.

The board has no significant connections rather than a reset button and an LED: No UART, I2C or external flash is used, but the hex file I sent is ignoring this. Since Bluetooth projects work well, I can think only of a hardware dependency on ZStack examples like the UART console.

Is there any example that does not use any peripheral by default other than a switch or LED? Is it enough to remove some predefined symbols like the use of UART?

Alternative would be to become a HEX from you but since I have no buttons, commissioning should be triggered automatically. 

Thanks in Advance.

Regards,

Angel

You should remove the BOARD_DISPLAY_USE_UART to disable the UI, attached is an image for you to try (CC1352R SDK v3.10, channel 11) with the same behavior as desired:

https://e2e.ti.com/cfs-file/__key/communityserver-discussions-components-files/158/zr_5F00_light_5F00_CC1352R1_5F00_LAUNCHXL_5F00_tirtos_5F00_ccs.hex

Regards,
Ryan

Hi Ryan,

First of all thanks for the file. Could you please describe what it should do? Which channel are you using? I loaded the file to my board but nothing is seen OTA. I do a flash erase before and load the HEX to make sure nothing is blocking the execution.

This is turning frustrating since SmartRF can easily be used to TX/RX in any channel without problems, so it is for sure not a hardware issue. Is there something else required by the ZigBee examples? Or is there any specific RF setting/tuning in SW that should be adjusted? In case it is important, my device is Rev. E (2.1) as read with Uniflash.

Thanks in advance.

Regards,

Angel

Hi Ryan,

ZDApp_NetworkInit and ZDO_StartDevice are executed indeed. Since I could not find any difference, I decided to try a 802.15.4 example and see if the lack of higher layers would let me debug the RF configuration. In this case the board was sending packets! confirming again that the antenna was working. +

Giving a second try to the ZigBee example, the board was surprisingly sending beacons. While testing further we have encountered small hardware issues, especially regarding power and ground planes, that could be affecting the RF side while debugging. Therefore, before discussing any further and imply other unrelated things, we would rework the design and come back to this topic if necessary.

Thanks for your support so far.

Regards,
Angel

Glad to hear you are making progress Angel. As one last comment, make sure that your are completely erasing flash (therefore resetting NV items) every time you program the device.

Regards,
Ryan