Radio test in 802.15.4 -mode

RE: Radio test in 802.15.4 -mode

ovrebekk — Mon, 05 Jul 2021 10:54:13 GMT

Please open a new ticket for these kind of requests, rather than add a new question to an old case.

In your case it seems you are not writing to the START task of the RNG?
If you don't do this no random number generation will be started.

Best regards
Torbjørn

RE: Radio test in 802.15.4 -mode

_maibi — Thu, 01 Jul 2021 04:38:08 GMT

/**
 * @brief Function for generating an 8-bit random number with the internal random generator.
 */
static uint32_t _rnd8(void)
{
    NRF_RNG->EVENTS_VALRDY = 0;

    while (NRF_RNG->EVENTS_VALRDY == 0)
    {
        // Do nothing.
    }
    return NRF_RNG->VALUE;
}


/**
 * @brief Function for generating a 32-bit random number with the internal random generator.
 */
static uint32_t _rnd32(void)
{
    uint8_t  i;
    uint32_t val = 0;

    for (i = 0; i < 4; i++)
    {
        val <<= 8;
        val  |= rnd8();
    }
    return val;
}


/**@brief Function for configuring the radio in every possible mode.
 *
 * @param[in] mode    Radio mode.
 * @param[in] pattern Radio transmission pattern.
 */
static void radio_config(nrf_radio_mode_t mode, transmit_pattern_t pattern)
{
    // Reset Radio ramp-up time.
    NRF_RADIO->MODECNF0 &= (~RADIO_MODECNF0_RU_Msk);

    // Packet configuration:
    // Bit 25: 1 Whitening enabled
    // Bit 24: 1 Big endian,
    // 4-byte base address length (5-byte full address length),
    // 0-byte static length, max 255-byte payload .
    NRF_RADIO->PCNF1 = (RADIO_PCNF1_WHITEEN_Enabled << RADIO_PCNF1_WHITEEN_Pos) |
                       (RADIO_PCNF1_ENDIAN_Big << RADIO_PCNF1_ENDIAN_Pos) |
                       (4UL << RADIO_PCNF1_BALEN_Pos) |
                       (0UL << RADIO_PCNF1_STATLEN_Pos) |
                       ((sizeof(m_tx_packet) - 1) << RADIO_PCNF1_MAXLEN_Pos);
    NRF_RADIO->CRCCNF = (RADIO_CRCCNF_LEN_Disabled << RADIO_CRCCNF_LEN_Pos);

    NRF_RADIO->TXADDRESS   = 0x00UL; // Set the device address 0 to use when transmitting
    NRF_RADIO->RXADDRESSES = 0x01UL; // Enable the device address 0 to use to select which addresses to receive

    // Set the address according to the transmission pattern.
    switch (pattern)
    {
        case TRANSMIT_PATTERN_RANDOM:
            NRF_RADIO->PREFIX0 = _rnd8();
            NRF_RADIO->BASE0   = _rnd32();
            break;

        case TRANSMIT_PATTERN_11001100:
            NRF_RADIO->PREFIX0 = 0xCC;
            NRF_RADIO->BASE0   = 0xCCCCCCCC;
            break;

        case TRANSMIT_PATTERN_11110000:
            NRF_RADIO->PREFIX0 = 0xF0;
            NRF_RADIO->BASE0   = 0xF0F0F0F0;
            break;

        default:
            return;
    }


    switch (mode)
    {
     #ifdef NRF52840_XXAA
        case RADIO_MODE_MODE_Ieee802154_250Kbit:
        {
            // Packet configuration:
            // S1 size = 0 bits, S0 size = 0 bytes, payload length size = 8 bits, 32-bit preamble.
            NRF_RADIO->PCNF0 = (RADIO_LENGTH_LENGTH_FIELD << RADIO_PCNF0_LFLEN_Pos) |
                               (RADIO_PCNF0_PLEN_32bitZero << RADIO_PCNF0_PLEN_Pos) |
                               (RADIO_PCNF0_CRCINC_Exclude << RADIO_PCNF0_CRCINC_Pos);
            NRF_RADIO->PCNF1 = (IEEE_MAX_PAYLOAD_LEN << RADIO_PCNF1_MAXLEN_Pos);

            NRF_RADIO->MODECNF0    |= (RADIO_MODECNF0_RU_Fast << RADIO_MODECNF0_RU_Pos);
        } break;

        case RADIO_MODE_MODE_Ble_LR500Kbit:
        case RADIO_MODE_MODE_Ble_LR125Kbit:
        {
            // Packet configuration:
            // S1 size = 0 bits, S0 size = 0 bytes, payload length size = 8 bits, 10-bit preamble.
            NRF_RADIO->PCNF0 = (0UL << RADIO_PCNF0_S1LEN_Pos) |
                               (0UL << RADIO_PCNF0_S0LEN_Pos) |
                               (RADIO_PCNF0_PLEN_LongRange << RADIO_PCNF0_PLEN_Pos) |
                               (2UL << RADIO_PCNF0_CILEN_Pos) |
                               (3UL << RADIO_PCNF0_TERMLEN_Pos) |
                               (RADIO_PCNF0_CRCINC_Exclude << RADIO_PCNF0_CRCINC_Pos) |
                               (RADIO_LENGTH_LENGTH_FIELD << RADIO_PCNF0_LFLEN_Pos);
            NRF_RADIO->PCNF1 = (RADIO_PCNF1_WHITEEN_Enabled << RADIO_PCNF1_WHITEEN_Pos) |
                               (RADIO_PCNF1_ENDIAN_Little << RADIO_PCNF1_ENDIAN_Pos) |
                               (3UL << RADIO_PCNF1_BALEN_Pos) |
                               (0UL << RADIO_PCNF1_STATLEN_Pos) |
                               ((sizeof(m_tx_packet) - 1) << RADIO_PCNF1_MAXLEN_Pos);

            // Set fast ramp-up time.
            NRF_RADIO->MODECNF0 |= (RADIO_MODECNF0_RU_Fast << RADIO_MODECNF0_RU_Pos);

            // Set CRC length; CRC calculation does not include the address field.
            NRF_RADIO->CRCCNF = (RADIO_CRCCNF_LEN_Three << RADIO_CRCCNF_LEN_Pos) |
                                (RADIO_CRCCNF_SKIPADDR_Skip << RADIO_CRCCNF_SKIPADDR_Pos);
        } break;
     #endif // NRF52840_XXAA

        case RADIO_MODE_MODE_Ble_2Mbit:
        {
            // Packet configuration:
            // S1 size = 0 bits, S0 size = 0 bytes, payload length size = 8 bits, 16-bit preamble.
            NRF_RADIO->PCNF0 = (0UL << RADIO_PCNF0_S1LEN_Pos) |
                               (0UL << RADIO_PCNF0_S0LEN_Pos) |
                               (RADIO_PCNF0_PLEN_16bit << RADIO_PCNF0_PLEN_Pos) |
                               (RADIO_LENGTH_LENGTH_FIELD << RADIO_PCNF0_LFLEN_Pos);
        } break;

        default:
        {
            // Packet configuration:
            // S1 size = 0 bits, S0 size = 0 bytes, payload length size = 8 bits, 8 -bit preamble.
            NRF_RADIO->PCNF0 = (0UL << RADIO_PCNF0_S1LEN_Pos) |
                               (0UL << RADIO_PCNF0_S0LEN_Pos) |
                               (RADIO_PCNF0_PLEN_8bit << RADIO_PCNF0_PLEN_Pos) |
                               (RADIO_LENGTH_LENGTH_FIELD << RADIO_PCNF0_LFLEN_Pos);
        } break;
    }
}

It should be worked.

RE: Radio test in 802.15.4 -mode

ovrebekk — Fri, 09 Oct 2020 09:06:50 GMT

Correct, the radio_test example is very simple, and doesn't use any protocol per se.

For basic RF testing this is not really required.

Best regards
Torbjørn

RE: Radio test in 802.15.4 -mode

mrono — Thu, 08 Oct 2020 11:53:05 GMT

Reality is sinking in slowly... All this time I've had it on my mind that we're dealing with MAC level packets. With addresses and crcs and all that. But the radio test has none of that. I've looked at the code quite a while, even traced some of the register values, but it wasn't until I started adding some filtering that it dawned on me that we're dealing with bare PHY packets.

So all we have is the synchronization header, a length byte (PHR), and a payload full of fixed values. No addresses, not even a crc. I guess it might be possible to add the crc calculation even if there is no actual MPDU, but I'm not sure.

What I'm going to do is simply check that the payload matches the expected fixed pattern, that'll be good enough in my case.

RE: Radio test in 802.15.4 -mode

ovrebekk — Thu, 08 Oct 2020 08:33:26 GMT

I don't have a lot of experience with 802.15.4-based protocols, but based on the product specification it seems you are correct.

Any packet matching the synchronization header field (consisting of 4 bytes of preamble and 1 byte SHR) will be accepted by the radio, assuming the CRC is OK.

Then the destination address will have to be decoded from the packet by the software.

Best regards
Torbjørn

RE: Radio test in 802.15.4 -mode

mrono — Wed, 07 Oct 2020 09:36:34 GMT

[quote userid="2116" url="~/f/nordic-q-a/66277/radio-test-in-802-15-4--mode/273419#273419"]Did you ever see any packets come in if you don't enable the TX at all?[/quote]

I think I did. I'll need to recheck.

We have things here in the office that use a proprietary 802.15.4-based protocol to communicate, so that seemed the most plausible explanation.

Now that I think about it.. The address matching is done in software, right? I recall struggling with it when we first implemented support for our protocol for the nRF52840. The radio driver needed to do quite a bit of work filtering packets intended for other recipients.

And since the radio test code is very simple, there is no software address matching. So this is probably the cause.

RE: Radio test in 802.15.4 -mode

ovrebekk — Wed, 07 Oct 2020 09:33:02 GMT

Hi Markku

Thanks a lot for the update. I made the same changes myself and verified that this made the example work.

I didn't notice the counter issues you experienced though, I get the right number of packets on the RX side depending on how many packets I send from the TX. How often do you see this occur?

Did you ever see any packets come in if you don't enable the TX at all?

Best regards
Torbjørn

RE: Radio test in 802.15.4 -mode

mrono — Tue, 06 Oct 2020 11:50:08 GMT

If you set the other PCNF1 fields (balen, endian, whiteen) to zero in 802.15.4-mode, the reception works again. That makes PCNF1 equal to the way it was in SDK 15.3. I'm not sure if everything is correct after that, or if there is something else needed also.

I did also notice that the received packets counter occasionally ends up higher than the number of packets I sent. The rx counter increments every time a CRCOK event occurs. So I'm guessing that in 802.15.4-mode the receiver counts every valid packet, even those sent to other devices? I have not checked this further though.

RE: Radio test in 802.15.4 -mode

ovrebekk — Tue, 06 Oct 2020 11:26:39 GMT

Hi Markku

I did some testing on my own, and it seems I am experiencing the same issue. In 802.15.4 mode I am not able to receive any packets.

I will have to look into this a bit more and get back to you.

Best regards
Torbjørn

RE: Radio test in 802.15.4 -mode

mrono — Mon, 05 Oct 2020 08:06:42 GMT

[quote userid="2116" url="~/f/nordic-q-a/66277/radio-test-in-802-15-4--mode/272564#272564"]Have you tried to read out the content of the PCNF1 register from the two configurations to see how it differs?[/quote]

I checked this now. PCNF1 is set as I expected.

In SDK 15.3, when using 802.15.4-mode PCNF1 is 0x7F. So only MAXLEN is set.

In SDK 15.3, using BLE 1Mbit-mode PCNF1 is 0x030400FF. So MAXLEN = FF, BALEN = 4, ENDIAN = 1 and WHITEEN = 1.

In SDK 17.0.2, 802.15.4-mode gives 0x0304007F. So MAXLEN is correct, but BALEN, ENDIAN and WHITEEN are also set.

BLE_1Mbit-mode in SDK 17.0.2 is identical to the earlier SDK.

RE: Radio test in 802.15.4 -mode

ovrebekk — Thu, 01 Oct 2020 13:26:12 GMT

Hi Markku

Thanks for the detailed report, I will try to reproduce the issue.

Have you tried to read out the content of the PCNF1 register from the two configurations to see how it differs?

Best regards
Torbjørn

RE: Radio test in 802.15.4 -mode

mrono — Wed, 30 Sep 2020 13:58:43 GMT

I've tried to compare the radio test examples from SDKs 15.3 and 17.0.2. A lot has changed, but I found something interesting among the changes.

In SDK 15.3 the function radio_config writes directly to the radio registers.

First it unconditionally writes this to the PCNF1 register:

// Packet configuration:
// Bit 25: 1 Whitening enabled
// Bit 24: 1 Big endian,
// 4-byte base address length (5-byte full address length),
// 0-byte static length, max 255-byte payload .
NRF_RADIO->PCNF1 = (RADIO_PCNF1_WHITEEN_Enabled << RADIO_PCNF1_WHITEEN_Pos) |
(RADIO_PCNF1_ENDIAN_Big << RADIO_PCNF1_ENDIAN_Pos) |
(4UL << RADIO_PCNF1_BALEN_Pos) |
(0UL << RADIO_PCNF1_STATLEN_Pos) |
((sizeof(m_tx_packet) - 1) << RADIO_PCNF1_MAXLEN_Pos);

A few lines later it checks if we wanted 802.15.4 -mode, and does this:

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

So it overwrites the previously set PCNF1 configuration.

SDK 17 does almost the same thing, but uses a configuration struct:

/* Packet configuration:
* payload length size = 8 bits,
* 0-byte static length, max 255-byte payload,
* 4-byte base address length (5-byte full address length),
* Bit 24: 1 Big endian,
* Bit 25: 1 Whitening enabled.
*/
memset(&packet_conf, 0, sizeof(packet_conf));
packet_conf.lflen = RADIO_LENGTH_LENGTH_FIELD;
packet_conf.maxlen = (sizeof(m_tx_packet) - 1);
packet_conf.statlen = 0;
packet_conf.balen = 4;
packet_conf.big_endian = true;
packet_conf.whiteen = true;

And again a few lines later, if 802.15.4 was requested:

packet_conf.maxlen = IEEE_MAX_PAYLOAD_LEN;

But done this way, the previous contents of packet_conf are not overwritten. And PCNF1 ends up different than in SDK 15.3.

If I add code to reset the other PCNF1 fields (balen, big_endian, whiteen) to zero, I can receive 802.15.4 packets again.

So this looks like a mistake made during refactoring. Although the original way was in my opinion a nasty surprise to leave for the future maintainer.

Could someone at Nordic check if I'm on the right track here?

RE: Radio test in 802.15.4 -mode

mrono — Wed, 30 Sep 2020 11:33:19 GMT

Ok, if I take the radio test code from SDK 15.3 I can receive using the same procedure.

The 15.3 radio test doesn't have a rx packet counter, but by varying the tx payload an printing the received payload I can see that it does receive the correct packet at least once.

RE: Radio test in 802.15.4 -mode

mrono — Wed, 30 Sep 2020 11:07:45 GMT

Some further things I tried:

Tried the other payload pattern (11110000)

Explicitly set the tx power, even though the default was fine for my tests

Verified that the code catches the mistake if I try to set a channel not between 11-26

To rule out the Keil tools I flashed the precompiled radio_test_pca10056.hex to the DKs using nRF Connect Programmer

None of this changed a thing.

RE: Radio test in 802.15.4 -mode

mrono — Wed, 30 Sep 2020 10:20:03 GMT

I feel like I must have a simple mistake somewhere, as this is just not working at all. So here is again what I'm doing:

Two nRF52840DKs, both new, both version 2.0.1

I program both with the radio test example from SDK 17.0.2. I use Keil for compiling and programming in case that matters.

Open two terminals to send commands. I used putty.

Issue the following commands for both DKs:

data_rate ieee802154_250Kbit
transmit_pattern pattern_11001100
start_channel 16
end_channel 16

All commands were successful, and the DKs responded accordingly.

Now on one DK start reception: (start_rx)

And on the other start transmitting 500 packets: (start_tx_modulated_carrier 500)

Once the transmitter prints that it is finished, print the receive status on the receiver: (print_rx)

The result I'm seeing is that nothing was received.

Now I change the mode to BLE (data_rate ble_1Mbit) on both units. Restart rx, resend the 500 packets.

Printing results shows that all 500 packets were received.

RE: Radio test in 802.15.4 -mode

mrono — Wed, 30 Sep 2020 05:39:24 GMT

I tried 11 and 26. The radio test even prints a message if you try to use an invalid channel, so I don't think this was an issue.

RE: Radio test in 802.15.4 -mode

ovrebekk — Tue, 29 Sep 2020 07:47:32 GMT

Hi Markku

Which RF channel are you using?

As mentioned in the example documentation the start and end channel must be in the 11 to 26 range when using the IEEE 802.15.4 mode.

Best regards
Torbjørn

RE: Radio test in 802.15.4 -mode

mrono — Mon, 28 Sep 2020 09:58:32 GMT

I got new DKs now. PCA10056 v2.0.1

Now I get no reception whatsoever in ieee802154_250Kbit mode. Doing as described in the first post, the packet counter stays at zero all the time. Changing mode (data_rate) to ble_1Mbit makes the reception successful.

To clarify, I'm using the radio test example from SDK 17.0.2 as is, not modified in any way. And two new nRF52840 DKs.

RE: Radio test in 802.15.4 -mode

ovrebekk — Wed, 23 Sep 2020 14:08:43 GMT

Hi Markku

Thanks for the update. Please test again when you got the new DK's, and let us know if you're still experiencing issues.

Best regards
Torbjørn

RE: Radio test in 802.15.4 -mode

mrono — Wed, 23 Sep 2020 12:28:07 GMT

Based on the date code I probably have an Engineering A version.... I didn't even remember I had a DK this early.

And the Errata 110 would explain what I'm seeing:

Consequences

Might lose packets in BLE LR or 802.15.4 mode. Might lose some sensitivity in BLE and proprietary mode.

Workaround

Always disable the radio after having received a packet (using TASK_DISABLE).

Ugh. I have ordered a few more DKs.

RE: Radio test in 802.15.4 -mode

mrono — Wed, 23 Sep 2020 12:06:18 GMT

Ok, I think I may have a hardware revision issue. One of my DKs is actually a Preview DK. PCA10056 v0.9.2

I used this PDK as the receiver in the tests I did earlier. Now I tried to reverse the roles, and this unit hangs when trying to start transmitting.

Is this expected? I need to check the HW revisions but was there an issue like this on some earlier revision?

I don't have a third DK at the moment to test.