• State Verified Answer
  • Replies 9 replies
  • Subscribers 65 subscribers
  • Views 329 views
  • Users 0 members are here
Attachments (0)
Nordic Case Info
  • Case ID: 324469
Options

ADDRESS affects radio rampup time?

SebastianA

We had a strange problem with a test case of ours. We use the radio in 1Mbps BLE mode and send two packets, then receive one packet.

Our test case normally works, but fails when we use address 0x4F7D2A92 for our packets.

We need to send the packet at a specific time and we don't want to have the radio turned on too early in order to save energy. So we trigger TXEN and START via PPIs from TIMER0's COMPARE 0 & 1. With the address above, the time between our events were too short so the READY even came just after we sent START. It also seems like the RX rampup can be shorter or longer depending on the address being used.

Are these correct observations?

Parents
  • 0

    I was measuring the time for the START/READY event to happen via IO pins and an oscilloscope. When I instead store the time of the READY signal via TIMER0's CAPTURE[2] and compare it to COMPARE[0], it always seem to be 40us later. Is there a sub-us clock that could affect this?

    If all I change in our test is the address, it works/doesn't work depending on the address. If I change the time allowed for rampup from 40 to 42us it works fine with the above address as well.

    Our code once reads access_address from UICR, then does this every time before using the radio:
        nrf_radio_base0_set((access_address & 0x00ffffff) << 8);
        nrf_radio_prefix0_set((access_address & 0xff000000) >> 24);


    That's the only thing in our code that depends on the address.

    When it doesn't work, from what I can see is that we don't get a DISABLED event. We use a PPI to send DISABLE when a timeout happens and we have a short and PPI group to disable that timeout when ADDRESS events happens. We also have the END->DISABLE short enabled.

    When we don't receive a packet, the timeout happens for this address and we get the DISABLED event.

    With the address mentioned above we don't get it. I've checked that we get the ADDRESS event by letting it also toggle a pin.

    We've configured the radio with a maxlen of 255 for the packet and we've reserved 20ms for the time slot. Even if the length field in the packet would become incorrectly received, we should still have enough time to receive the whole, invalid packet and get a DISABLED event.

    Could the ADDRESS value affect anything else here?

Reply
  • 0

    I was measuring the time for the START/READY event to happen via IO pins and an oscilloscope. When I instead store the time of the READY signal via TIMER0's CAPTURE[2] and compare it to COMPARE[0], it always seem to be 40us later. Is there a sub-us clock that could affect this?

    If all I change in our test is the address, it works/doesn't work depending on the address. If I change the time allowed for rampup from 40 to 42us it works fine with the above address as well.

    Our code once reads access_address from UICR, then does this every time before using the radio:
        nrf_radio_base0_set((access_address & 0x00ffffff) << 8);
        nrf_radio_prefix0_set((access_address & 0xff000000) >> 24);


    That's the only thing in our code that depends on the address.

    When it doesn't work, from what I can see is that we don't get a DISABLED event. We use a PPI to send DISABLE when a timeout happens and we have a short and PPI group to disable that timeout when ADDRESS events happens. We also have the END->DISABLE short enabled.

    When we don't receive a packet, the timeout happens for this address and we get the DISABLED event.

    With the address mentioned above we don't get it. I've checked that we get the ADDRESS event by letting it also toggle a pin.

    We've configured the radio with a maxlen of 255 for the packet and we've reserved 20ms for the time slot. Even if the length field in the packet would become incorrectly received, we should still have enough time to receive the whole, invalid packet and get a DISABLED event.

    Could the ADDRESS value affect anything else here?

Children
Related