Using extended advertising data with nRF52833

RE: Using extended advertising data with nRF52833

Einar Thorsrud — Wed, 19 Apr 2023 11:59:47 GMT

[quote user="BBI"]If it's that simple[/quote]

I think debugging what you have is faster than starting from scratch (and being able to debug is anyway essential). (And when you have an issue you see/reproduce consistently, finding out what you can from debugging is normally more efficient than staring at the code.)

[quote user="BBI"]Using a J-Link debugger, I stepped through the code and found that the last line before it resets is line 663 in ble_advertising.c.[/quote]

I see. But it does not "just" reset. What kind of reset is it? What causes the reset? You can for instance start with checking the RESETREAS when the device comes back up to see what type of reset it was.

Regarding logs, it is expected you don't get logs at you use deferred logging and the reset happens before logs are processed. If you disable deferred logging (set NRF_LOG_DEFERRED to 0 in your sdk_config.h), you will see the logs.

So, I did a quick debug session with your application now, and then I see that the RESETREAS is 0x00010000. That was a bit suprising to me as it means wakeup from system off mode, but that is what is says. So I put a break point in the call to sleep_mode_enter(), and that is why the device enters system off mode, after BLE_ADV_EVT_IDLE. Commenting out that sleep prevents the reset.

Edit: Looking a bit further, it times out immediately as you start fast advertising:

err_code = ble_advertising_start(&m_advertising, BLE_ADV_MODE_FAST);

but you have disabled fast advertising in your advertising_init() function:

    init.config.ble_adv_fast_enabled     = false;//true;

And the way the advertising module state machine works is that it will start at the top, and skip any non-enabled modes. As you have no modes that are enabled, it will time out immediately.

RE: Using extended advertising data with nRF52833

BBI — Wed, 19 Apr 2023 11:07:37 GMT

Using a J-Link debugger, I stepped through the code and found that the last line before it resets is line 663 in ble_advertising.c.

I have attached my original code for the beacon, from before any extended advertising was added. If it's that simple, could you please change the configs and inits so that extended advertising can be used? The code is very lightly modified, just a merge of the beacon and UART peripherall examples.
devzone.nordicsemi.com/.../Beacon.7z

RE: Using extended advertising data with nRF52833

Einar Thorsrud — Wed, 19 Apr 2023 07:38:18 GMT

I have had a look but did not spot anything obvious. It is easy to miss things though, so debugging and logging would make sense to learn more first. A reset does not happen by itself, so getting logging to work and debugging. The first question is what exactly causes the reset? With that information, we know much more on where to look.

Regarding line 663 in ble_advertising.c, that calls the callback you have registered, which is the on_adv_evt() function in your main(). I do not see any obvious issues there, neither with this function itself or how you pass the pointer to it. How did you conclude that this is the last thing that happens before the reset?

RE: Using extended advertising data with nRF52833

BBI — Tue, 18 Apr 2023 14:09:32 GMT

The RTT logger has stopped working since I made the last set of changes to the beacon, so I can't see if any errors are being returned. What I mean when I say the code "breaks" at line 663: p_advertising->evt_handler(p_advertising->adv_evt); in ble_advertising.c is that the device resets and starts running from main() again as soon as it executes this line. I'm unsure if this is where the issue lies or if it is due to the code in advertising_init() or advertising_start(). Could you please at least take a look at the advertising_init() or advertising_start() functions?

RE: Using extended advertising data with nRF52833

Einar Thorsrud — Tue, 18 Apr 2023 12:57:24 GMT

Can you elaborate more about what you mean by "code breaks"? Do you get an error returned from somewhere? Or what else do you find when debugging?

RE: Using extended advertising data with nRF52833

BBI — Mon, 17 Apr 2023 14:35:08 GMT

Thank you; the Scanner appears to be working now. However, I'm still struggling to get the Beacon to work. The code breaks at the ble_advertising_start(&m_advertising, BLE_ADV_MODE_FAST); function, which leads to ble_advertising.c. I think the problem occurs at line 663: p_advertising->evt_handler(p_advertising->adv_evt);. The issue could also lie in the advertising_init() or advertising_start() functions, or within the sdk_config. Could you please have another look at the code.

devzone.nordicsemi.com/.../Extended_5F00_Advertising_5F00_Tests_5F00_3.7z

RE: Using extended advertising data with nRF52833

Einar Thorsrud — Mon, 17 Apr 2023 10:56:35 GMT

Hi,

sd_ble_gap_scan_start() will return NRF_ERROR_INVALID_LENGTH if the provided buffer length is invalid. This is set by NRF_BLE_SCAN_BUFFER in your sdk_config.h. And for extended this needs to be larger than 31 which you have set. See this snippet from ble_gap.h:

/**@defgroup BLE_GAP_SCAN_BUFFER_SIZE GAP Minimum scanner buffer size
 *
 * Scan buffers are used for storing advertising data received from an advertiser.
 * If ble_gap_scan_params_t::extended is set to 0, @ref BLE_GAP_SCAN_BUFFER_MIN is the minimum scan buffer length.
 * else the minimum scan buffer size is @ref BLE_GAP_SCAN_BUFFER_EXTENDED_MIN.
 * @{ */
#define BLE_GAP_SCAN_BUFFER_MIN                    (31)                             /**< Minimum data length for an
                                                                                         advertising set. */
#define BLE_GAP_SCAN_BUFFER_MAX                    (31)                             /**< Maximum data length for an
                                                                                         advertising set. */
#define BLE_GAP_SCAN_BUFFER_EXTENDED_MIN           (255)                            /**< Minimum data length for an
                                                                                         extended advertising set. */
#define BLE_GAP_SCAN_BUFFER_EXTENDED_MAX           (1650)                           /**< Maximum data length for an
                                                                                         extended advertising set. */
#define BLE_GAP_SCAN_BUFFER_EXTENDED_MAX_SUPPORTED (255)                            /**< Maximum supported data length for

RE: Using extended advertising data with nRF52833

BBI — Mon, 17 Apr 2023 10:42:06 GMT

I've managed to fix the code so that it doesn't hardfault. It seems there was an error in porting the code. I'm still getting some errors, though. On the Scanner/Central side, I get an error code 0x9, which is NRF_ERROR_INVALID_LENGTH. This occurs in the scan_start function, which goes to line 1122 in nrf_ble_scan.c. sd_ble_gap_scan_start(&p_scan_ctx->scan_params, &p_scan_ctx->scan_buffer); is what gives me the error code. To which length is this referring, and where can I fix it?

These are my scan parameters. When I change .extended to 0, the code works as expected.
static ble_gap_scan_params_t m_scan_param = /**< Scan parameters requested for scanning and connection. */
{
.active = 0x01,
.interval = NRF_BLE_SCAN_SCAN_INTERVAL,
.window = NRF_BLE_SCAN_SCAN_WINDOW,
.filter_policy = 0, // BLE_GAP_SCAN_FP_WHITELIST,
.timeout = 0,
.scan_phys = BLE_GAP_PHY_1MBPS,
.extended = 1,
};

On the Beacon/Peripheral side, the code runs for a while, but then gives me a fatal error. I'm not sure what's causing the error. I also can't detect the Beacon using the nRF app on my phone. I've tested it with another app that scans for BLE devices as well.

Could you please have a look at my code and suggest any fixes? I'm using pca10100 and soft device s140.
Kind regards
devzone.nordicsemi.com/.../Extended_5F00_Advertising_5F00_Tests_5F00_2.7z

RE: Using extended advertising data with nRF52833

Einar Thorsrud — Thu, 13 Apr 2023 12:59:12 GMT

Hi,

There is no fundamental reason this should not work on the nRF52833. Have you done any debugging to understand what happens before / why you get the hardfault? And is it really a hardfault and not another error? If it is a hardfault, then make sure you have HARDFAULT_HANDLER_ENABLED set to 1 in sdk_config.h. If you den test a debug build with DEBUG defined, you should end up in a breakpoint in components/libraries/hardfault/hardfault_implementation.c. If you have logging enabled you also get this information in the log.