CC8530: Pairing is not working (receiver)

If it helps, here are the results of the additional tests I was able to run in PurePath Wireless Commander:

prod_test_pairing:
Program Autonomous Application (master): OK
Program Autonomous Application (slave): OK
Pairing autonomous master/slave: FAILED (WASP network formation failed (status: 8a05)

prod_test_simplerf_auto:
All steps work (including RF test RX and RF TEST TX).

prod_test_simplerf_rx and prod_test_per_auto:
All tests failed (except for Program Test Image and Program Application Image)

I rarely manage to run tests from RX/TX Test, or they end in a few seconds with “Communication failure: Make sure that the device contains a product test image. If the problem persists, check hardware and connections,” but my hardware never disconnects (it is always marked as available) and it does not seem to be an image flash problem.

Hello David, 

We have a 2.4 GHz design review in case that can help you here, SIMPLELINK-2-4GHZ-DESIGN-REVIEWS Design tool | TI.com. With that being said its interesting that some tests work and others do not, I am not as familar with the CC85xx device so its a little difficult to tell what could be the origin of the issue. 

Thanks,
Alex F

Hello Alex,

I have already sent an email to TI about this, and I am waiting for a response.
But when analyzing the network, I can clearly see that signals are being transmitted by my prototypes. I had also planned a version of the prototype that would allow switching using external antennas, and I am having the same problem with that as well.

Hello David,

I wanted to ask if what you are trying to accomplish is similar in effort to the CC85XXDK-HEADSET User’s Guide, (the PCB design). 

As for purepath since we are copying the same code here as the example it should work assuming everything else is the same, so I would pend on the design review to see if that can catch anything. 

Thanks,
Alex F

Yes, I have already tested the software made for CC85XXDK-HEADSET, but it doesn’t work either.

I have already spend time to compare my schematic with reference design, but nothing differs (in my opinion)

Hello David,

I see that another internal thread was made here, so I wanted to let you know that I am also looking into that thread for you. 

From your original post, paring is indicating some sort of problem here as the TX/RX can't pair with each other correctly. Have you already tried different pairing settings to see if that affects it in PurePath Commander/Configurator? 

Thanks,
Alex F

Hello Alex,

As indicated in my post, I have test both pairing methods. By the way, I have also test pairing via network ID.

Hello David,

David Minard said:

prod_test_pairing:
Program Autonomous Application (master): OK
Program Autonomous Application (slave): OK
Pairing autonomous master/slave: FAILED (WASP network formation failed (status: 8a05)

prod_test_simplerf_auto:
All steps work (including RF test RX and RF TEST TX).

prod_test_simplerf_rx and prod_test_per_auto:
All tests failed (except for Program Test Image and Program Application Image)

I rarely manage to run tests from RX/TX Test, or they end in a few seconds with “Communication failure: Make sure that the device contains a product test image. If the problem persists, check hardware and connections,” but my hardware never disconnects (it is always marked as available) and it does not seem to be an image flash problem.

Before you run these tests can you do a chip reset, then download your firmware and do a chip info read (through device manager) I want to double check that the firmware is getting flashed correctly; you indicated above that the device never disconnects but we do get some communication error report. 

During your tests try to limit outsider interference with your antennas "but antennas may also be used if the test area is protected against interference from other RF sources." 

Can you use the default sofware set up .ppwptc file? (the example only one), and for the failing tests can you provide the log files. 

Thanks,
Alex F

Hello Alex,

To avoid any issues, I disabled all nearby Wi-Fi networks during my tests.

As indicated in your instructions, I used the PurePath Wireless Commander software to:

- Perform a chip reset (on all 3 chips: MASTER, SLAVE, and TESTER), no errors

- Click on “Program Tester” (to flash the tester), no error: PASSED Programming tester

- Flash the cards with the sample program “prod_test_pairing.ppwptc”

Both cards were flashed successfully, but I have the same error as before in the logs, namely:

PASSED [213F71EF@MASTER] Program Autonomous Application (master)

PASSED [213F71EF@MASTER] COMPLETE TEST SEQUENCE, 1 tests.

PASSED [213F71E1@SLAVE] Program Autonomous Application (slave)

FAILED WASP network formation failed (status: 8a05)

FAILED [213F71E1@SLAVE] Pairing autonomous master/slave

FAILED [213F71E1@SLAVE] COMPLETE TEST SEQUENCE, 2 tests. (1 failed).

Here is what Chip Info / Device Info returns on the Master:

And here is what it returns on the Slave:

I then performed a second test, this time flashing the devices from PurePath Wireless Configurator.

After flashing both cards, here is the result (to my knowledge, we can see that the firmware is written correctly because the chip info is different for each chip, compared to the previous screenshots).

Here is the result of this second flash on the Master:

Here is the result of this second flash on the Slave:

I hope it can helps

Hello David,

Looking at your provided images it does seem like the devices are getting flashed correctly (though the size of the image seems consistent?). 

I wanted to ask if we could check the Crystal Oscillator's accuracy here, as when the devices connect they share the master's audio clock, it could be that the Crystal Oscillator which feeds into the CC8530 device could be causing some type of issue that prevents the paring of the device due to devices needed to be "synchronous" with each other. 

Further info "protocol slave nodes are only allowed to transmit data at times explicitly stated by the protocol master" & "All traffic goes from or to the protocol master, never between protocol slave nodes." 

Also I noticed in the datasheet that we could maybe force the network's ID between the two CC8530's "It is also possible to program the network ID into the protocol slaves during production", could we try this to see if they pair?

Per section 2.4.2, the CC8530 acting as the slave may not be transmitting the paring packet to the Master, as you mentioned above that the master does seem to start paring before stopping and going back to alone:

"Following the protocol master packet is the slave join packet slot. This is reserved for protocol slaves that wish to join the audio network. If the audio network has the maximum number of supported protocol slaves, this slot is removed.

 Then each of the protocol slaves transmits their packets at the time offset in the timeslot announced by the protocol master in its packet. Each protocol slave packet contains:" 

Thanks,
Alex F