802.15.4 Test dev migration to 52840

[zzzLNAWS2]

Working on a migrating RF test firmware that was working on 52832 using SPI to AT86RF233(for 802.15.4). Was able to exercise PHY with that setup to send specific packet with few issues. I can't seem to figure out the secret combination of register values to make the same thing happen with 52840. As an example, I want to send this packet:

01 00 01 FF C1 FB E8 4C 90 72 8B E7 B3 51 89 63 AB 23.....with CRC == 0xA4 0xE3 stuck on the end. As mentioned, this was done using AT86RF233 which can be seen by test equipment and sniffers. I've got a constant carrier working on the 52840 but a packet with bytes seems to be more difficult than the equivalent procedure using BLE(such as DTM!!)

What am I missing? I've set:

static uint8_t Eight02_packetHeaderLFlen = 0;///*3 /**< Length of length field in packet Header (in bits). */
static uint8_t Eight02_packetHeaderS0len = 0;///*3 /**< Length of S0 field in packet Header (in bytes). */
static uint8_t Eight02_packetHeaderS1len = 0;///*3 /**< Length of S1 field in packet Header (in bits). */
static uint8_t Eight02_packetHeaderPlen = RADIO_PCNF0_PLEN_32bitZero;///*3 /**< Length of the preamble. */
static uint8_t Eight02_crcConfSkipAddr = 2;///*3 /**< Eight02 CRC calculation starting at first byte after length field. */
static uint8_t Eight02_static_length = 0;///*3 /**< Number of bytes sent in addition to the var.length payload. */
static uint32_t Eight02_balen = 3;///*3 /**< Base address length in bytes. */
static uint32_t Eight02_endian = RADIO_PCNF1_ENDIAN_Little;///*3 /**< On air endianess of packet, this applies to the S0, LENGTH, S1 and the PAYLOAD fields. */

static uint32_t Eight02_whitening = RADIO_PCNF1_WHITEEN_Disabled;///*3 /**< Whitening disabled. */
static uint8_t Eight02_crcLength = RADIO_CRCCNF_LEN_Two;///*3 /**< CRC Length (in bytes). */
static uint32_t Eight02_crc_poly = 0x00011021;///*3 /**< CRC polynomial. */
static uint32_t Eight02_crc_init = 0x00000000;///*3 /**< Initial value for CRC calculation. */

#define Eight02_HEADER_OFFSET 0 /**< Index where the header of the pdu is located. */
#define Eight02_HEADER_SIZE 1 /**< Size of PDU header. */
#define Eight02_LENGTH_OFFSET (Eight02_HEADER_OFFSET) /**< Index where the length of the payload is encoded. */

typedef struct
{
uint8_t content[Eight02_HEADER_SIZE + Eight02_MAX_PAYLOAD_SIZE]; /**< PDU packet content. */
} Eight02_pdu_type_t;

#define Eight02_MV887060A_0001_CONTENT {0x01,0x00,0x01,0xFF,0xC1,0xFB,0xE8,0x4C,0x90,0x72,0x8B,0xE7,0xB3,0x51,0x89,0x63,0xAB,0x23}///*3 ONLY PACKET CONTENTS - CRC

The Wireless_uart example looks quite convoluted compared to what I think i need to do.

Thanks

 

   

[zzzLNAWS2]

Any news JH?

Thanks

[Jørgen Holmefjord]

I did try out your application, and it does not seem to send any valid 802.15.4 packets. I will debug the application some more to figure out why it is not working. I cannot see any obvious issues at the moment.

[zzzLNAWS2]

Any news JH? I'm running out of time.

Thanks

[Jørgen Holmefjord]

There seems to be some issue with your packet configuration registers. Please try with the following:

NRF_RADIO->PCNF0    = (Eight02_packetHeaderLFlen    << RADIO_PCNF0_LFLEN_Pos) |
                      (Eight02_packetHeaderPlen     << RADIO_PCNF0_PLEN_Pos)  |
                      (RADIO_PCNF0_CRCINC_Include   << RADIO_PCNF0_CRCINC_Pos);

NRF_RADIO->PCNF1    = (EIGHT02_PAYLOAD_MAX_SIZE     << RADIO_PCNF1_MAXLEN_Pos);

I'm able to sniff the packets with these configurations.

[zzzLNAWS2]

That did it. It appears as though there are 3 things that need to be changed from the toggle source:

1. PCNF1_BALEN CANNOT be set to 3. I just left it there as an artifact of a copy/paste from the BLE source. The PS says it has a valid range of [2..4]. I didn't even notice that it's default is actually 0 if you never write it. So, I guess 0 is also a valid (and important) value in this case. i.e. it's not disregarded while only being used for BLE.

2. PCNF0_CRCINC must be 1. I was leaving it at default (0) under the assumption that it was unnecessary because it's not used for the BLE packets and that CRC doesn't live in RAM. Also, if you ctrl+F CRCINC in the PS, there is exactly 1 result in the section covering registers. There should probably be a little better explanation of its use as it pertains to 802.15.4.

3. Up the EIGHT02_TOGGLE_CONTENT_SIZE to 18 from 16. With 16 set, the data gets truncated to 0x0D + CRC. Changing to 18 gets all data to 0x0F + CRC.

Thank you very much for your help!