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

 

   

[Jørgen Holmefjord]

Hi,

Have you looked at the 802.15.4 driver available on our GitHub page? This should fit in quite nicely between using the registers directly, and the 802.15.4 libraries in the SDK.

Best regards,
Jørgen

[zzzLNAWS2]

Thanks for you response JH. I have read through this. And, although it may fit nicely, it still doesn't really answer the question as to whether or not direct register control will actually work to TX/RX an 802.15.4 PHY packet. The process outlined in 6.20.12.6/7 of the PS seems pretty straight forward. Is the outlined process supposed to work per the PS? (otherwise, why include the process).

My entire approach has used direct register control for the testing procedure. As stated, I appreciate your response. But, adding this driver muddies the water with other secondary issues like resource allocation, arbitration, softdevice requirements, new peripheral dependencies, etc. etc. etc.... most of which i'm not even sure of at this point considering the driver implementation has its' own NEW learning curve....as apposed to just setting up a few registers and dumping bytes into PACKETPTR.

So, can you help? Thanks again