calling nrf_ble_scan_filter_set breaks debugging.

RE: calling nrf_ble_scan_filter_set breaks debugging.

sschumac — Tue, 05 May 2020 16:55:09 GMT

Thank you for the assistance Edvin!

RE: calling nrf_ble_scan_filter_set breaks debugging.

Edvin — Tue, 05 May 2020 06:50:03 GMT

You shouldn't really flash via SES when you have a bootloader, because of the bootloader. Even though you use the same project that the .hex file was generated from, SES doesn't use the .hex file when you flash it. It uses the .elf or .out file (don't remember which one on this IDE). However, this file is a little different from the hex file that the bootloader settings is generated from (different padding on [u]intN_t, N = 8, 16. This will ruin the bl_settings, because the CRC of the application will change. The details are not important, but in SES, there is an option in the "tools" menu, called "Attach debugger". Use this so that SES doesn't flash anything.

Of course, remember to program the application hex file in your script. When you do this, you can debug your application in SES, even though SES hasn't flashed it directly. Just add the line:

nrfjprog --program Output/Debug/Exe/ble_app_buttonless_dfu_pca10056_s140.hex --verify

before the "nrfjprog --reset" line, and use the "Attach Debugger" feature.

BR,

Edvin

RE: calling nrf_ble_scan_filter_set breaks debugging.

sschumac — Tue, 05 May 2020 03:04:20 GMT

Your assumptions are correct, I have just found the issue is only present when flashing the image via SES (which I was doing implicitly by hitting the play button).

When I use the project output from SES build and flashing via the command line, it appears to be working as expected, attaching the debugger via SES shows the correct output!

After running this script

mkdir files
make -j9 -C ../../../../../dfu/secure_bootloader/pca10056_s140_ble/armgcc
cp ../../../../../dfu/secure_bootloader/pca10056_s140_ble/armgcc/_build/nrf52840_xxaa_s140.hex files/bl.hex 
cp ../../../../../dfu/private.key files/private.key

nrfutil settings generate --family NRF52840 --application Output/Debug/Exe/ble_app_buttonless_dfu_pca10056_s140.hex --application-version 1 --bootloader-version 1 --bl-settings-version 1 --key-file files/private.key files/bl_settings.hex

nrfjprog -e
nrfjprog --program files/bl_settings.hex
nrfjprog --program files/bl.hex
nrfjprog --reset

I can flash the application via SES with the lines commented and it works as expected

When I run that script again, and then rebuild and reflash via SES with the lines uncommented, the chip goes into bootloader mode. Not exactly sure why flashing via SES works without those lines and stops working with them.

As seeing as this is an issue localized to only SES flashing, I am at least grateful I can continue on with development.

RE: calling nrf_ble_scan_filter_set breaks debugging.

Edvin — Mon, 04 May 2020 07:17:22 GMT

Hello,

I am trying to figure out what issue you are seeing, and whether or not the issue is what you actually think it is.

Would you agree that if the device is stuck inside nrf_ble_scan_filter_set(), and never move on, then advertising_start() would never be called?

Would you agree that if advertising_start() would never be called, then you would not be able to connect to it?

The file that I sent you is a project based on your project where I am able to connect. I want to rule out that the issue is related to:

1: Your build setup

2: Your bootloader or your bootloader settings generation

3: Debugging method

4: HW

So. Are you able to connect to the attached hex file? And do you agree that if you can connect to it, nrf_ble_scan_filter_set() is called successfully, given that you believe that I included that function call in the .hex file?

Please correct me if any of my assumptions are incorrect.

RE: calling nrf_ble_scan_filter_set breaks debugging.

sschumac — Thu, 30 Apr 2020 17:40:28 GMT

I can flash that file and connect to it, to confirm, that application hex is successfully calling nrf_ble_scan_filter_set?
If so, I will audit all of my build steps again and update this thread with the verified answer. Still a bit confused on how a faulty build step could create an issue where one application hex will boot and the other wont, under the same exact build and load steps.

RE: calling nrf_ble_scan_filter_set breaks debugging.

Edvin — Thu, 30 Apr 2020 10:47:08 GMT

Try to flash the attached file:

devzone.nordicsemi.com/.../nw_5F00_ex.hex

Remember to erase the flash first. The attached file is a merge of the softdevice and all the other needed files. Are you able to connect to this one?

BR,

Edvin

RE: calling nrf_ble_scan_filter_set breaks debugging.

sschumac — Wed, 29 Apr 2020 23:48:34 GMT

Apologies, there is a chance I sent you the hex with the filter_set commented (which is working for me)
I just tried your exact build commands with both hexes, and found the same result. Working with the comments, not working without.

I am on an unmodified NRF52840 DK.

On a side note, I was under the impression the -bl-settings-version was supposed to be 2 for SDK versions >15.3.0, is that no longer the case?

Thanks to your comments, I did see the app was getting stuck in the bootloader when the lines were uncommented. I am not sure how uncommenting those lines can cause the bootloader to no longer think there is a valid application in flash (application flash placement?)

For clarity, I renamed and tested both of these hexes so I didnt get one mixed again.
Can you confirm with the commands above, both are working for you?
devzone.nordicsemi.com/.../commented_5F00_filter_5F00_set_5F00_WORKING.hex

devzone.nordicsemi.com/.../uncommented_5F00_filter_5F00_set_5F00_NOT_5F00_WORKING.hex

RE: calling nrf_ble_scan_filter_set breaks debugging.

Edvin — Wed, 29 Apr 2020 10:14:08 GMT

I was able to run that application as well, and connect to it. The log said it was connected, so the application is not stuck.

Just to straighten up a few things.

You are indeed using a normal nRF52840 DK, right?

When you say that it is stuck in the softdevice, you did try to set a breakpoint before that function call to check that it was reached? I just want to check whether what you are seeing is not that the device is stuck in bootloader mode? Because when I tried to flash the file nRF_Connect_Programmer_1587578570497.hex, it was stuck in DFU mode. I guess because the bootloader settings doesn't match the application. Did you update the bootloader settings when you changed your application?

Have a look at the attached .bat script if you are not familiar with bootloader settings.

mkdir files
make -j9 -C ..\..\..\..\..\dfu\secure_bootloader\pca10056_s140_ble\armgcc
copy ..\..\..\..\..\dfu\secure_bootloader\pca10056_s140_ble\armgcc\_build\nrf52840_xxaa_s140.hex files\bl.hex 
copy ..\..\..\..\..\dfu\private.key files\private.key

nrfutil settings generate --family NRF52840 --application Output\Debug\Exe\ble_app_buttonless_dfu_pca10056_s140.hex --application-version 1 --bootloader-version 1 --bl-settings-version 1 --key-file files\private.key files\bl_settings.hex

nrfjprog -e
nrfjprog --program ..\..\..\..\..\..\components\softdevice\s140\hex\s140_nrf52_7.0.1_softdevice.hex --verify
nrfjprog --program Output\Debug\Exe\ble_app_buttonless_dfu_pca10056_s140.hex --verify
nrfjprog --program files\bl_settings.hex
nrfjprog --program files\bl.hex
nrfjprog --reset

RE: calling nrf_ble_scan_filter_set breaks debugging.

sschumac — Tue, 28 Apr 2020 15:48:14 GMT

Here is the application hex, outputted from ble_app_buttonless_dfu/pca10056/s140/ses/Output/Debug/Exe/ble_app_buttonless_dfu_pca10056_s140.hex

devzone.nordicsemi.com/.../5050.ble_5F00_app_5F00_buttonless_5F00_dfu_5F00_pca10056_5F00_s140.hex

RE: calling nrf_ble_scan_filter_set breaks debugging.

Edvin — Tue, 28 Apr 2020 07:15:57 GMT

[quote user="sschumac"]On pausing the execution I get dropped into a branch execution somewhere in softdevice address space.[/quote][quote user="sschumac"]If I try and resume execution, the processor will Hard Fault. [/quote]

This is not unexpected. The hardfault is caused by the pause in the execution, and when you pause, it may very well be running in the softdevice.

Can you compile the application and send me the hex file? Please also tell me the path to where you copied the application hex file from.

Best regards,

Edvin

RE: calling nrf_ble_scan_filter_set breaks debugging.

sschumac — Tue, 28 Apr 2020 05:47:03 GMT

I have copied the files to a fresh SDK copy, as well as made your prescribed modifications to the SES project, but am still running into the same issue.

My exact steps for reproduction with the files moved into a clean SDK are as follows.

1. Build the bootloader via gcc
2. mergehex the bootloader with the s140 softdevice 7.0.1

3. nrfjprog program the chip with --chiperase, with the merged bootloader softdevice hex
4. Build the application in SES, build configuration = Debug
5. generate a bootloader settings page with

nrfutil settings generate --family NRF52840 --application {SES_OUTPUT_DIR_HERE} --application-version 1 --bootloader-version 1 --bl-settings-version 2 ./Output/settings.hex;

6. merge the settings hex file with the application hex file
7. program with nrfjprog with the --sectorerase flag

When I do steps 4 though 7 with those lines commented out, I get the expected behavior of the application, with my debugging logs showing up in SES console, and source maps working as expected.

When I redo steps 4 though 7 with those lines uncommented, I do not get the expected output from SES.

No RTT logs, will not fault unless paused.

On pausing the execution I get dropped into a branch execution somewhere in softdevice address space.

If I try and resume execution, the processor will Hard Fault.

RE: calling nrf_ble_scan_filter_set breaks debugging.

Edvin — Mon, 27 Apr 2020 09:38:16 GMT

Thank you,

Do I understand your description correctly if the issue was that if you uncommented the commented lines in this snippet, the bottom APP_ERROR_CHECK(err_code) was never reached?

static void scan_init(void)
{
    ret_code_t          err_code;
    nrf_ble_scan_init_t init_scan;

    memset(&init_scan, 0, sizeof(init_scan));

    init_scan.p_scan_param     = &m_scan_param;
    init_scan.connect_if_match = true;
    init_scan.conn_cfg_tag     = APP_BLE_CONN_CFG_TAG;

    err_code = nrf_ble_scan_init(&m_scan, &init_scan, scan_evt_handler);
    APP_ERROR_CHECK(err_code);

    err_code = nrf_ble_scan_filters_enable(&m_scan,
                                           NRF_BLE_SCAN_NAME_FILTER,
                                           false);

//    APP_ERROR_CHECK(err_code);
//    err_code = nrf_ble_scan_filter_set(&m_scan,
//                                       SCAN_NAME_FILTER,
//                                       "Viecar");

    APP_ERROR_CHECK(err_code);

}

If that is the case, then I am not able to reproduce the issue.

Please note that I did a couple of changes:

I copied only the ble_app_buttonless folder to an unmodified SDK, and copied your folders:

shiftac_ble_elm327_interface_c
shiftac_controller_service

to the ble_app_buttonless folder, and included this path to the preprocessor's user include directories (which is the proper way to include .h files. Don't include them in the project explorer, like you did), and I removed all files in your project explorer's "Shiftac Services" folder, and re-included the .c files (only!), so now it looks like this:

Can you try this?

Is the APP_ERROR_CHECK() on the bottom of the scan_init() reached?

Or did I misunderstand your issue?

If the issue remains after copying it into a clean, unmodified SDK, and including the custom files like described above, what output .hex file do you use? the "Debug" or "Release" configuration?

Let me know if any of the instructions wasn't clear.

RE: calling nrf_ble_scan_filter_set breaks debugging.

sschumac — Fri, 24 Apr 2020 15:40:58 GMT

Apologies!

Also yes, that is correct,

SDK 16.0.0, SES

Here is the full SDK zip with my custom services

devzone.nordicsemi.com/.../3010.sdk_5F00_16_5F00_app.zip

RE: calling nrf_ble_scan_filter_set breaks debugging.

Edvin — Fri, 24 Apr 2020 06:39:51 GMT

Hello,

I assume you are using SDK16.0.0 and SES?

Can you please upload the ble_app_buttonless_dfu.zip with the content of the pca10056 folder as well? All I saw was the main.c file and the IAR project file, but the folders:

hex
pca10040
pca10040e
pca10056
pca10056e

Were all empty. I can't compile the project with only the main.c file, because I see that you have included a lot of files.

Try unzipping your zip file in an unmodified SDK before uploading it, to make sure that it behaves as you expect. Remember that that is the way the project will behave on my computer.

RE: calling nrf_ble_scan_filter_set breaks debugging.

sschumac — Fri, 24 Apr 2020 03:13:10 GMT

I have tried flipping the auto connect setting, I tried removing const from adapter_name, with no dice.

Ill try seeing what I can do FEATURE_JLINK_MONITOR

RE: calling nrf_ble_scan_filter_set breaks debugging.

hmolesworth — Fri, 24 Apr 2020 01:05:09 GMT

Unlikely long shot, maybe DMA is involved, try removing "const"

static char const adapter_name[7] = "Viecar";

static char adapter_name[7] = "Viecar";

Also try J-Link Monitor which allows you to single step debug while the SoftDevice runs happily in the background without dropping the BLE connection. Try this which I just posted in another stream (assuming you don't already have it enabled):

#if defined(FEATURE_JLINK_MONITOR)
   // This allows all interrupts higher than _PRIO_SD_LOW (ie 4, BLE SD stuff) to continue execution even during a break
   // note Two J-Link commands are required in command file:
   // SetMonModeDebug = 1
   // SetMonModeVTableAddr = ADDR
   //  where ADDR is the application's vector table located in FLASH, ie the start address for the
   // application, probably either 0x1B000 or 0x1C000 or 0x26000 depending on SoftDevice
   // See https://github.com/NordicPlayground/j-link-monitoring-mode-debugging
   NVIC_SetPriority(DebugMonitor_IRQn, _PRIO_SD_LOW);
#endif

Enable FEATURE_JLINK_MONITOR in the project preprocessor (so it's easy to turn feature on and off). Add the commands noted above in Debug->J-Link->Command Options for SES; other IDEs are similar, I use both SES and IAR.

RE: calling nrf_ble_scan_filter_set breaks debugging.

hmolesworth — Fri, 24 Apr 2020 00:57:33 GMT

You did try allowing the match, I suppose (I have it true):

    err_code = nrf_ble_scan_filters_enable(&m_scan,
                                           NRF_BLE_SCAN_NAME_FILTER,
                                           true); //<==

RE: calling nrf_ble_scan_filter_set breaks debugging.

sschumac — Thu, 23 Apr 2020 23:28:46 GMT

Unfortunately, I did try this as well, more as a sanity check that something else wasn't broken. This section of the docs have led me to believe this is supported as well.

Filters can be set and removed dynamically while the application is running, regardless of whether they are enabled or disabled.

RE: calling nrf_ble_scan_filter_set breaks debugging.

hmolesworth — Thu, 23 Apr 2020 22:59:47 GMT

I would suggest filter_set() must be invoked prior to filters_enable(), worth a try :-)

RE: calling nrf_ble_scan_filter_set breaks debugging.

sschumac — Thu, 23 Apr 2020 22:45:33 GMT

What I have tried:

1. Increasing the ram start for more SD ram (by up to 5kb)

2. Re-flashing the SD and Bootloader

3. replacing the string literal in the call with static const char adapter_name[] (although it works with a string literal in my other project)

4. If I pause and restart the debugger enough, a HardFault is thrown (I am assuming because its trying to perform a debugging action with no debugger explicitly attached), the value at (xSP+0x18) does not bring me to an instruction in my own code.

I havent done any more HardFault debugging, as the CPU does not fault unless I do strange things with the debugger.