802.15.4 callback Issues

RE: 802.15.4 callback Issues

Marte Myrvold — Wed, 02 Feb 2022 12:20:49 GMT

Hi,

I have been trying to look internally, but I cannot find anywhere stating why this function is needed. However, I see that it is called at the beginning of main() in the 802.15.4 Wireless UART example as well. I suspect that it is necessary for RADIO IRQ to work and be handled correctly.

Best regards,

Marte

RE: 802.15.4 callback Issues

Andreas3T — Wed, 02 Feb 2022 11:55:47 GMT

I found the actual issue or at least what made active scan work.

Calling

ral_irq_handlers_import()

was required for active scan to properly work. I have no way of telling why, I'm not using the RAL module at all and it isn't mentioned in the documentation as an requirement.

RE: 802.15.4 callback Issues

Marte Myrvold — Tue, 01 Feb 2022 10:33:41 GMT

Hi Andreas,

Good to hear that the issue solved itself, even if you had to reinstall everything 🙂

Thank you for sharing your code here for others to find, it is greatly appreciated!

Best regards,

Marte

RE: 802.15.4 callback Issues

Andreas3T — Tue, 01 Feb 2022 08:38:47 GMT

Due to some OS issues noticed when installing wireshark I ended up reinstalling Ubuntu from scratch and the development environment as well of course. For some reason everything started working fine after this without any changes in the code.

If I had to guess the reason for the issue it could have been the wrong compiler version or that the 802.15.4 binary was corrupt. If anyone else have similar issues I will leave the correct code for making an active scan below.

Note that scan type and scan duration is hardcoded in the example.

Thanks Marte for the help.

#define CONFIRM_SCAN_SIZE 7
void mlme_scan_conf_cb(mlme_scan_conf_t * scan_report)
{
   NRF_LOG_INFO("Status: %X", scan_report->status);
   if(scan_report->status == MAC_SUCCESS)
   {
      if(scan_report->result_list_size > CONFIRM_SCAN_SIZE )
      {
         NRF_LOG_INFO("Number of results surpassed memory allocated in scan");
      }

      NRF_LOG_INFO("Received 802.15.4 scan report");
      NRF_LOG_INFO("Found %d PANs", scan_report->result_list_size);
      NRF_LOG_INFO("unscanned channels: %X", scan_report->unscanned_channels);

      for(int i = 0; i < scan_report->result_list_size; i++ )
      {
         NRF_LOG_INFO("Found PAN with ID: %X", scan_report->pan_descriptor_list[i].coord_pan_id);
      }
   }

}

static mlme_scan_req_t *scan_request;
void scan()
{
   scan_request = (mlme_scan_req_t *)malloc(sizeof(mlme_scan_req_t));
   ASSERT(scan_request != NULL);

   scan_request->pan_descriptors_buf = (mac_pan_descriptor_t *) malloc(sizeof(mac_pan_descriptor_t) *  CONFIRM_SCAN_SIZE);
   scan_request->pan_descriptors_buf_size =  CONFIRM_SCAN_SIZE;
   scan_request->energy_detect_buf = malloc(sizeof(uint8_t) *  CONFIRM_SCAN_SIZE);
   scan_request->energy_detect_buf_size =  CONFIRM_SCAN_SIZE;

   ASSERT(scan_request->energy_detect_buf != NULL);
   ASSERT(scan_request->pan_descriptors_buf != NULL);

   uint32_t channelMask;
   channelMask = 0b00000111111111111111100000000000;
   scan_request->scan_type = 1;
   scan_request->scan_channels = channelMask;
   scan_request->scan_duration = 4;

   mlme_scan_req(scan_request, mlme_scan_conf_cb);
   NRF_LOG_INFO("Scanning");
}

Best Regards,
Andreas

RE: 802.15.4 callback Issues

Andreas3T — Mon, 31 Jan 2022 15:03:13 GMT

Hi Marte,

Just got hands on a second nrf52840 to use as sniffer. Will come back with logs later today or possibly tomorrow.

Thanks for the checkup.

Best Regards,
Andreas

RE: 802.15.4 callback Issues

Marte Myrvold — Mon, 31 Jan 2022 14:54:06 GMT

Hi Andreas,

Have you managed to get a sniffer log of the active scan?

Best regards,

Marte

RE: 802.15.4 callback Issues

Andreas3T — Wed, 26 Jan 2022 11:47:58 GMT

I have confirmed that macAutoRequest is set to true. What I find odd is that the confirm primitive is never called when an Active scan is requested regardless if there is a coordinator in the vicinity or not.

Will come back with results from nRF sniffer, thanks.

Best Regards, Andreas

RE: 802.15.4 callback Issues

Marte Myrvold — Wed, 26 Jan 2022 11:08:39 GMT

Hi Andreas,

I am happy to hear that!

[quote user="Andreas3T"] passive scan returns MAC_NO_BEACON which might be correct[/quote]

This sounds like the correct behavior. With passive scan the device can locate a coordinator transmitting beacon frames within its personal operating space (POS). The device does not, however, transmit a beacon requests during a passive scan.

[quote user="Andreas3T"]I'm not sure if a Zigbee coordinator requires some additional settings to periodically send a beacon signal.[/quote]

To periodically send beacon frames the network must be a beacon-enabled PAN. In such a network you will have at least one device transmitting beacon frames at a regular interval. When this is not the case, the coordinator will only send beacons as a response to a beacon request.

[quote user="Andreas3T"]Does active scan have additoinal requirements than passive and ED scans?[/quote]

The scans differ in how they work at least. With ED (energy detection) scan the device performs an energy detection measurement on the different channels, while during active scan the device transmits a beacon request and waits to receive a beacon. The Zigbee coordinator should have responded to the beacon request with a beacon frame.

Do you know wheter macAutoRequest is set to true or false? For active and passive scans, the MLME-SCAN.confirm primitive will only include a set of PAN descriptor values of the scan is successful and macAutoRequest is set to TRUE. If not, it will contain a null set of PAN descriptor values.

Do you have an additional nRF52840 Dongle or DK? If so, you can use it as a sniffer to capture packets using our nRF Sniffer for 802.15.4. This might help in finding out where the issue is, as you will be able to see if the device sends a beacon request during the active scan or not, and whether the Zigbee coordinator responds to the beacon. If you upload the sniffer log as a pcap file I can look at it to see if I find any issues with the network traffic.

Best regards,

Marte

RE: 802.15.4 callback Issues

Andreas3T — Wed, 26 Jan 2022 08:50:40 GMT

Thanks for the quick reply.

I see then most of my issues seems to be resolved.

After trying each type of scan except orphan scan, ED scan seems to work as intended, passive scan returns MAC_NO_BEACON which might be correct, a Zigbee Coordinator is setup close to the device as a test but I'm not sure if a Zigbee coordinator requires some additional settings to periodically send a beacon signal.

However the Active scan never returns no matter what, according to the standard it should return after the scan duration with a confirm. Does active scan have additoinal requirements than passive and ED scans?

Best Regards, Andreas

RE: 802.15.4 callback Issues

Marte Myrvold — Tue, 25 Jan 2022 14:02:31 GMT

Hi,

From what I can find it seems like calling sys_task_run() is required, but I will check with the developers to make sure.

It is not required to use sys_mm_alloc(). There are some other cases where using this to allocate memory leads to the scan request callback not being called: https://devzone.nordicsemi.com/f/nordic-q-a/56163/nrf-802-15-4-stack-api-mlme_scan_req-does-not-call-the-callback-function and https://devzone.nordicsemi.com/f/nordic-q-a/59282/802-15-4-mlme_scan_req-never-calls-it-s-callback-function-802-15-4-library-mlme_scan_request_primitive-is-not-according-to-802-15-4_2006-spezification.

I checked internally, and I cannot find cases of sys_mm_alloc being used for the MLME-SCAN-request or MLME-RESET.request. It is used to allocate memory for packets, for example:

test_packet_t * packet_to_send = (test_packet_t *)sys_mm_alloc(sizeof(test_packet_t));

But scan and reset request are mostly done in the same way as in the comment of the first case I link to above:

static mlme_reset_req_t mlme_reset_req_container =
  {
    .set_default_pib = true
  };

  mlme_reset_req(&mlme_reset_req_container, SetupSeqResetMlmeCb);

Not that I am aware of, but I will check this out.

No, the source code for the library is unfortunately not publicly available.

I will talk with the developers and see if they might have any ideas as to why the scan confirmation data is as it is.

Best regards,

Marte