CC2652R: CC2652R + CC2592 configuration failing with Zigbee Example Projects.

Hello Akhilesh,

I do not have any recommendations beyond those already provided in the previous thread.  Have you disabled BTN-1 operation, overwritten the radio_config files for new power tables, and implemented the correct Z-Stack TX power APIs?  Are you using a different SIMPLELINK-CC13X2-26X2-SDK version than before?  I would advise making as few changes as possible from your original setup and retracing your steps wherever possible.  How are you confirming that the Zigbee RF is not acting as expected? Here is the guide for properly disabling SysConfig.

Regards,
Ryan

Hi Ryan,

I haven't disabled BTN-1 button I have chosen a different IO for it in SysConfig, made a similar for LED as well.

I have not made any changes to the radio_config file, the table also is not changed because the chip output is the same and CC2592 will amplify the output. This is the same configuration done in Smartrf_settings generated by SmartRf Studio where it is working fine

No changes to ZStack TX power APIs either. I am using the example zr_GenericApp as base with updates to Pins(so no code changes)

I am using the same ZStack 3.40.00.2, however there might have been a SysConfig update.

I am using a Sniffer for the RF packets.

----

One observation I have made is that the code works fine on  CC2652R (without CC2592), which makes me think the CC2592 connections are not configured correctly, because in my previous test, the code for CC2530+CC2592 does not work for the non-amplifier  CC2530 chip.

Is this observation correct ?

Thanks
Akhilesj

Hi Akhilesh,

SysConfig updates alongside the SDK and therefore if you are using the same SIMPLELINK-CC13X2-26X2-SDK version then the SysConfig version is unchanged.  Make sure that BoardGpioInitTable and gpioPinConfigs of ti_drivers_config.c have been modified correctly.  You may need to step through your code in a debug session to make sure the device registers are acting in accordance with your expected code revisions.

Regards,
Ryan

Hi Ryan,

I have ensured all the files have been modified correctly. The registers are also configured as per TIDC-CC2650-CC2592-EMK document. However no RF Tx is being generated.

To further test, I set the Pins to GPIO and set a manual config to the PA and LNA pins for TX(i.e. PA=1 , LNA=0). In this case, the a Tx signal was being generated but the whole application seems to crash before the entire signal is generated. The sniffer shows an "Unknown Command" for the Beacon request.

Also while performing the Tx test from SmartRF Studio I can see the PA pin being asserted(connected the io pin to an led ), but I don't think that is happening in the application, despite peforming the RFCore configurations. It feels like the PA and LNA pins are not configured during the Beacon message attempt(the IOC registers are correctly configured where the application requests the beacon).

If I have to debug, is there any specific code where I can check if the PA and LNA pins are switching correctly(in the RF layer ?). I have take the zr_genericApp and am sniffing the Beacon on Button press to check the Tx behaviour.

Thanks
Akhilesh

Hi Akhilesh,

You have confirmed that this same hardware works when evaluating inside of SMARTRFTM-STUDIO, that similar hardware was previously working with a revised ZR genericapp Z-Stack project from SIMPLELINK-CC13X2-26X2-SDK v3.40, and your new station is using CCS v9.3?  I would recommend that you restart and implement all code changes on a fresh project import, if this does not work then please send me a description of all project & code changes.  I unfortunately do not have similar hardware to test with.  You would need to analyze the specific GPIO pins during runtime to confirm that they are operating properly.  I also suggest that you confirm that the board works with the v3.20 SDK (non-SysConfig implementation)

Regards,
Ryan

Hi Ryan,

I am using a revised ZR genericapp Z-Stack project from SIMPLELINK-CC13X2-26X2-SDK v3.40 on CCS v9.3.

I imported fresh zr_genericapp code and tried the following to sniff the beacon on button press:

1. Remapping default board IO pins and configuring 2 GPIO outputs, PA and LNA.
PA is put to always HIGH and LNA is always LOW(RF Tx configuration for CC2592). I did not configure these to pins to the RF CORE GPOx.
Beacon is generated and captured on sniffer on button press, but only when the PA and LNA GPIO outs are configured to LOW drive strength. If I increase the Drive strength to medium or high the application crashes when attempting to send Beacon.

2. Remapping board IO pins and configuring 2 GPIO pins, PA and LNA, to be mapped to the RF Core
PA and LNA gpios are initialized and then mapped as LNA to RFC_GPO0 and PA to RFC_GPO1.
No Beacon is generated on button press

** I have attached the readmes with my exact changes

I have also performed a few additional tests, i.e. the rfEchoTx and rfEchoRx. (uses Proprietary RF)
I programmed the default code into 2 Launchpads the the RF Echo test worked absolutely fine.
However, when I replace 1 of the Launchpads with my custom board with the same code the test fails, both on the custom CC2652(no amplifer) and the CC2652+CC2592 boards. I am not sure if any additional changes are required for my custom board.
Again, on verification with SmartRF Studio, even the Proprietary RF was getting scanned correctly.

**Another observation I made was that after a single attempt of RF Tx, in all the above cases, I could not read the RF Core registers while Debugging the code as "Unable to read".

I'm not sure if the hardware has any issues, so I have attached the schematics of the CC2652(no amplifier) and CC2652+CC2592. Please could you have a look

Thanks
Akhilesh

Attahcments

1. Force RF Tx, by forcing GPIO pins (Project Archive and readme)

/cfs-file/__key/communityserver-discussions-components-files/158/4024.Beacon_5F00_forceTx.zip

/cfs-file/__key/communityserver-discussions-components-files/158/1832.Beacon_5F00_forceTx_5F00_readme.txt

2. Use RF Core (Project Archive and readme)

https://drive.google.com/open?id=1lFIT6rc7R1zANNV0JsdNQEO3mxmpePxz (size 20500 kb, so need to use google drive. Readme encompasses the changes though)

/cfs-file/__key/communityserver-discussions-components-files/158/Beacon_5F00_RFCore_5F00_readme.txt

Schematics of Custom Boards
CC2652 : /cfs-file/__key/communityserver-discussions-components-files/158/ZGB_5F00_MOD_5F00_CC2652.pdf

CC2652+CC2592 : /cfs-file/__key/communityserver-discussions-components-files/158/ZGB_5F00_MOD_5F00_CC2652_2B00_CC2592.pdf

Target Configuration tested on Smart RF Studio

Akhilesh Premkumar said:

If I increase the Drive strength to medium or high the application crashes when attempting to send Beacon.

I need to know more about the call stack from the debugger when you state that the application crashes.

Akhilesh Premkumar said:

I programmed the default code into 2 Launchpads the the RF Echo test worked absolutely fine.
However, when I replace 1 of the Launchpads with my custom board with the same code the test fails, both on the custom CC2652(no amplifer) and the CC2652+CC2592 boards. I am not sure if any additional changes are required for my custom board.
Again, on verification with SmartRF Studio, even the Proprietary RF was getting scanned correctly.

Thank you for providing this additional information, I have notified HW and Proprietary SW experts to help comment on this behavior.  I suspect a HW issue but your CC2652R schematic is similar to the LAUNCHXL-CC26X2R1 so you may need to provide the board layout for further investigation.

Akhilesh Premkumar said:

**Another observation I made was that after a single attempt of RF Tx, in all the above cases, I could not read the RF Core registers while Debugging the code as "Unable to read".

Is the program running or paused during this time?

Regards,
Ryan

Hi Akhilesh. 

From your schematic "CC2652+CC2592", the chip is a CC2650 and not a CC2652. Is this the correct schematic? 

Regards,
Vegard

Hi Ryan, Vegard,

Ryan,

The condition from crash is actually not the drive strength. Instead the LF Clock Source in Device Configuration of SysConfig
LF Clock Source -> LF XOSC, the code crashes.
LF Clock Source -> Derived from HF XOSC. the beacon is generated on forcing PA(high) and LNA(low) for RF Tx.

I could not get the callstack, because the debugger itself gets disconnected with the following errors
Cortex_M4_0: Error: (Error -1170 @ 0x0) Unable to access the DAP. Reset the device, and retry the operation. If error persists, confirm configuration, power-cycle the board, and/or try more reliable JTAG settings (e.g. lower TCLK). (Emulation package 9.1.0.00001)
Cortex_M4_0: Trouble Halting Target CPU: (Error -2064 @ 0x0) Unable to read device status. Reset the device, and retry the operation. If error persists, confirm configuration, power-cycle the board, and/or try more reliable JTAG settings (e.g. lower TCLK). (Emulation package 9.1.0.00001)

--

Regarding RF Echo test, I have a CC2652R board prepared with pins exposed. I have just connected the programming pins from the XDS110 and programmed the RFEchoTx code as is. When need I'm using the LEDs of the launchpad itself.

--

Program is paused. In fact, peripherals(like UART, I2C, SPI etc.) also show "Unable to read", I can read IOC, GPIO and most others resistors.

--

Vegard,

It is correct. We are using the same schematic for CC2652 as well.

Thanks

Akhilesh

Hi Akhilesh,

This is indicating LF/HF crystal failure and you need to evaluate those physical components.  http://www.ti.com/lit/swra640 

Regards,
Ryan

Hi Ryan,

We are looking into the components.

I referred the document suggested and it says
"The high frequency crystal oscillator(HFXOSC), running at 24 MHz for CC13x0/CC26x0and 48 MHz for CC13x2/CC26x2,is mandatory to operate the radio.The low frequency crystal oscillator(LFXOSC) is used for RTC timing".
so as long as the HF is configured, the radio should work fine right ? since the 'Derived from HF XOSC' setting works fine for LF Clock Source ?

Also, the board seems to work absolutely fine with smartRF studio with the expected output.

This issue with the oscillator happens when I set the pins to GPIO outputs, but the RF core configuration with IOC configure set for RFC_GPOx, neither works nor crashes the application. What could be the reason for that ?

Thanks
Akhilesh

Zigbee is a synchronous protocol for which accurate RTC timing is required and therefore the LFXOSC cannot be sourced by the HFXOSC.  LF oscillator failure could cause Z-Stack crashing that may not occur with SMARTRFTM-STUDIO.

Regards,
Ryan

Hello,

Ok. We are checking the components.

We did another test in the meantime with the forced PA, LNA configuration for Tx mode.
We underwent the whole process of a pairing a zigbee router to the coordinator and also tested sending and receiving messages. Of course, this was limited to small network which was about 3-4m apart, but we were able to test the application.

We will try to replace the LF XOSC component and check, but just wanted to update you on the above test.

I had another question with regards to PA and LNA levels during TX/RX. Is this pin state update done automatically by hardware or is there some software responsible for this that is setting the pin levels based on whether we sending or receiving messages?

Thanks
Akhilesh

Another update on the Zigbee test performed i.e. pairing, send and receive.
This works only when the debug session is active and stops working when the session is stopped.

We are working on replacing the 32kHz component to perform another test.

Thanks
Akhilesh

Hi Ryan,

I have checked with the guys providing the CC2652 and CC2652+CC2592 boards and both are using the same LF XOSC component and following the previously shared designs

Considering the Zigbee communication works fine with the CC2652(no amplifier version) and we are able to perform all the tests, the problem might be with something else i.e. like us forcing the PA and LNA pins to specific states.

If we configure the pins as RF Core pins for PA and LNA, the application neither crashes nor sends any RF signal, even when using LF Clock source as LF XOSC.  This makes it feel like there is some other issue while sending messages with the amplifier settings. Do you have any suggestions that we can try ?

Thanks
Akhilesh

P.S.
If possible, could you configure some pins on the launchpad as RF Core pins and probe them to see if the PA and LNA pins are changing configuration during TX/RX ? I do not have access to an oscilloscope right now.

Board Images

Hi Akhilesh,

Unfortunately an oscilloscope is the best option for checking the PA/LNA pin configuration.  Are you able to verify correct operation of this amplified board design with other stacks (15.4, Prop RF, etc)?

Regards,
Ryan

Hello Ryan,

Yeah. I will be able to get an oscilloscope sometime next week. Will test this then.

However, I tested the same amplifier board design with the BLE stack, using Project Zero sample. Just setting IOCPortConfigureSet for RFC_GPO0 and RFC_GPO1 after changing the defaults pins being used by the application and amplifier board works absolutely fine. I can see the amplified performance on the BLE example.

The above change doesn't work for ZStack generic app, so there must be some additional changes required for the Zigbee example.

I had another doubt regarding BLE which uses the BIM_offchip. Our custom board doesn't have an external flash but the BIM_offchip never detects internal and external flash. What changes do I have to make the BLE example boot directly without BIM ?

Thanks
Akhilesh

Hi Ryan,

Any advice on why the BLE project zero example works fine with amplifier settings using IOCPortConfigureSet and no additional changes but the same doesn;t work with Z-Stack examples.

I have made the Pin usage changes on both as required. Is the RF layer not the same for both the stacks ?

Thanks
Akhilesh

Hi Akhilesh,

Thank you for updating the post and I am glad that you were able to access your other systems to help you further debug the issue.  As was alluded previously, 15.4-Stack and Z-Stack has additional RF checks and HW dependencies which will cause it to not operate if failure is detected, as is the case with the faulty HW described.  Please continue to debug the PCB issue with your additional reference points.

Regards,
Ryan