This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

802.15.4 Test dev migration to 52840

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


 

   

Parents Reply Children
  • 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    

      

  • Yes, the process in the PS is supposed to work. Just make sure you follow the guidelines in 6.20.12 (IEEE 802.15.4 operation). Could you upload your test project?

    The driver does come with some arbitration and resource requirements, but this is a standalone driver which do not depend on any softdevice/SDK/libraries/etc. The sample applications are quite simple and straight forward.

  • BLE_802154_packet_toggle.zip

    This is about as simple as I could make it because I'm sure you have better things to do than surf through mountains of comments from all that I have tried for the migration. Not to mention, other components are required in the real source and you don't need to be bothered with that. This file also has no issues with remaining public; maybe it will help someone else. I stripped out everything to leave only a loop in main that:

    1. Executes transmission of a 16-byte payload BLE packet formatted 0x00 0x01 0x02......0x0F. As mentioned earlier, PHY BLE packet structure for testing(not standard BLE packet).

    2. Executes transmission of a 16-byte payload 802.15.4 packet formatted 0x00 0x01 0x02......0x0F. Ditto on PHY only. 

    3. The 2 protocols will toggle back and forth every 500ms.

    4. LED1 of the pca10056 will flash when BLE is TXing and LED2 will flash when Eight02 is TXing.

    5. UART_DBG_INT(0xXX) outputs //DBG ints for simple UART debugging.

    6. pca10056 #defines EXT_UART_RX_PIN 30, EXT_UART_TX_PIN 31 using 921,600 8N1.

    7. BLE packet sends fine. Visible to RX code running on 52832. 

    8. I only added DBG in Eight02_send_packet() since that is where my problem is. DBG out is 0x02 0x04 0x05 0x06 0x0A...then repeats.

    Let me know if you need anything else. Thanks! 

  • 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.

Related