Possible "poison packet" problem with CC1120

Chip settings at both sides are as follows.

const tRfSettings rfSettings[] = {
0x0000, 0x06, // IOCFG3 GPIO3 IO Pin Configuration
0x0001, 0x02, // IOCFG2 GPIO2 IO Pin Configuration
0x0003, 0x06, // IOCFG0 GPIO0 IO Pin Configuration
0x0008, 0x04, // SYNC_CFG1 Sync Word Detection Configuration - No PQT gating, relaxed sync word soft decision threshold
0x000A, 0x48, // DEVIATION_M Frequency Deviation Configuration - 0x48=40kHz deviation
0x000B, 0x2E, // MODCFG_DEV_E Modulation Format and Frequency Deviation Configuration - 0x2E=40kHz deviation 4GFSK, 0x26=40kHz deviation 4FSK
0x000C, 0x04, // DCFILT_CFG Digital DC Removal Configuration
0x000D, 0x18, // PREAMBLE_CFG1 Preamble Length Configuration
0x000F, 0x00, // FREQ_IF_CFG RX Mixer Frequency Configuration
0x0010, 0x00, // IQIC Digital Image Channel Compensation Configuration
0x0011, 0x41, // CHAN_BW Channel Filter Configuration - 0x41=125kHz channel filter (0x02=100kHz)
0x0012, 0x46, // MDMCFG1 General Modem Parameter Configuration
0x0013, 0x05, // MDMCFG0 General Modem Parameter Configuration
0x0014, 0x9F, // DRATE2 Data Rate Configuration Exponent and Mantissa [19:16] - 99 99 9A = 50ks/s
0x0015, 0xBE, // DRATE1 Data Rate Configuration Mantissa [15:8] - 9E B8 52 = 60ks/s
0x0016, 0x77, // DRATE0 Data Rate Configuration Mantissa [7:0] - 9F BE 77 = 62ks/s
0x0017, 0x3C, // AGC_REF AGC Reference Level Configuration
0x0018, 0xEC, // AGC_CS_THR Carrier Sense Threshold Configuration
0x001A, 0x83, // AGC_CFG3 AGC Configuration
0x001B, 0x60, // AGC_CFG2 AGC Configuration
0x001C, 0xA9, // AGC_CFG1 AGC Configuration
0x001D, 0xC0, // AGC_CFG0 AGC Configuration
0x001E, 0x00, // FIFO_CFG FIFO Configuration
0x0020, 0x03, // SETTLING_CFG Frequency Synthesizer Calibration and Settling Configuration
0x0021, 0x12, // FS_CFG Frequency Synthesizer Configuration
0x0026, 0x04, // PKT_CFG2
0x0027, 0x04, // PKT_CFG1 Packet Configuration, Reg 1 - enable crc and do not append status
0x0029, 0x3F, // RFEND_CFG1 Stay in Rx after receiving packet
0x002A, 0x30, // RFEND_CFG0 Go to Rx after transmitting packet
0x002B, 0x77, // PA_CFG2 Power Amplifier Configuration, Reg 2
0x002D, 0x6B, // PA_CFG0 Power Amplifier Configuration, Reg 0
0x002E, 0xFF, // PKT_LEN Packet Length Configuration
0x2F00, 0x00, // IF_MIX_CFG IF Mix Configuration
0x2F01, 0x20, // FREQOFF_CFG Frequency Offset Correction Configuration - 0x20 disables correction after syncword
0x2F02, 0x0A, // TOC_CFG Timing Offset Correction Configuration
0x2F0C, 0x6B, // FREQ2 Frequency Configuration [23:16]
0x2F0D, 0xE6, // FREQ1 Frequency Configuration [15:8]
0x2F0E, 0x66, // FREQ0 Frequency Configuration [7:0]
0x2F12, 0x00, // FS_DIG1
0x2F13, 0x5F, // FS_DIG0
0x2F16, 0x40, // FS_CAL1
0x2F17, 0x0E, // FS_CAL0
0x2F19, 0x03, // FS_DIVTWO Divide by 2
0x2F1B, 0x33, // FS_DSM0 Digital Synthesizer Module Configuration, Reg 0
0x2F1D, 0x17, // FS_DVC0 Divider Chain Configuration, Reg 0
0x2F1F, 0x50, // FS_PFD Phase Frequency Detector Configuration
0x2F20, 0x6E, // FS_PRE Prescaler Configuration
0x2F21, 0x14, // FS_REG_DIV_CML
0x2F22, 0xAC, // FS_SPARE
0x2F27, 0xB4, // FS_VCO0 VCO Configuration, Reg 0
0x2F32, 0x0E, // XOSC5 Crystal Oscillator Configuration, Reg 5
0x2F36, 0x03, // XOSC1 Crystal Oscillator Configuration, Reg 1
0x2F8F, 0x48, // PARTNUMBER Part Number
0x2F90, 0x21, // PARTVERSION Part Revision
0x2F92, 0x10, // RX_STATUS RX Status
};

Due to vacation we don't have any software resources this week and hence we will not be able to write code shortterm that reproduces the problem. Is it possible in some way to trig this bug using Studio? Or if you have a TRXEB to write a short software piece that trigs the bug?

To be able to help we have to be able to reproduce it here and here in Oslo we don't have the DSP kit you are using.

We'll look into reproducing this using Studio.

It doesn't look like we can reproduce this using the SmartRF studio because we can't read the status byte after sending/receiving the packet sequence.

Is there an API we can use to program the devices via the USB interface without having to go through the GUI?

Thanks, Antony

Not that I'm aware of. DOes that mean you can't get hold of a TRXEB fast?

Sorry, to be clear yes we do have some TRXEBs also, the problem is that Studio doesn't let you directly issue the strobes or status byte read in the same way as the hardware.

Currently we can reproduce this using one TRXEB+CC1120+Studio and a C5515 EVM+CC1120+our code.

My colleagues have ported our code onto the MSP430 on the TRXEB, and this currently does not reproduce the problem.  This would suggest it's a race condition, something to do with the CC1120 going through the Rx->Rx state transition at the end of the packet while also picking up something from the data (perhaps a preamble false detection?) and receiving our IDLE strobe.  We'll have another look to see if we can make the TRXEB test case closer to the C5515 EVM by tweaking SPI clock speed etc, and will post here if we can.

It's very reproducible with the C5515 EVM as we are running in the IRQ that is triggered by a GPIO from the end of packet, and we're directly writing the SPI on the C5515 so timing is very precise.  We should be able to give you a code drop privately when you can get someone with the hardware combination above able to look into it.  I would very much appreciate it if you can try to reproduce this because the failure is rather serious even if it's a specific combination of data and control timing.

For now we have found a workaround using RFEND_CFG that avoids us having to send the IDLE strobe.  This is however only a temporary workaround as there are cases where we need to force the receiver into IDLE.

Thanks,

Antony

Ok, I'll check on Monday how easy/ fast it is to get hold of the EM you are using.

Could it be that the DSP is too fast?

- Is the SPI timing within what is given in the table on page 7 in the Userguide?

- Where is the timing different when using the MSP vs DSP? Is it possible to add delay if timing is a problem?

Sorry for the delay in responding, I was away last week.

Yes clock speed is within the table on Page 7, we're using 4MHz on both MSP and DSP.

We also experimented with delays in our DSP code given that it can run much faster than the MSP and this appeared to make no difference.

We now have our own hardware integrating C5515 DSP and CC1120 radio and see a slightly different issue, but a similar problem of the receiver failing to set up.

Our developer working on this is away this week.  But if you can borrow a C5515 EVM we should be able to provide demo code to reproduce the problem - is this possible for you?

From our side, would switching to the CC1125 fix the problem or be worth trying?  We have our own PCBs, is it a drop-in replacement?

Thanks,

Antony