SAFERTOS+BLE

RE: SAFERTOS+BLE

Vidar Berg — Thu, 28 Aug 2025 07:26:04 GMT

Of course. The sd_* API functions trigger a SVC exception by executing the SVC instruction shown in the disassembly view (please refer to "Application programming interface" for more details). This is supposed to invoke the Supervisor Call handler inside the SoftDevice. But my current suspicion is that safertos is changing the interrupt forwarding and causing the SVC interrupt to be forwarded directly to the application instead. Hope this helps.

RE: SAFERTOS+BLE

virendraVT — Thu, 28 Aug 2025 07:05:43 GMT

Thanks Vidar, Sorry to ask but could you elaborate more, what do you mean here?

RE: SAFERTOS+BLE

Vidar Berg — Thu, 28 Aug 2025 07:02:22 GMT

Sorry, I misread your previous reply and thought you were seeing the same issue with the SDK example. Please try single stepping from the SVC instruction to confirm whether program execution reaches the corresponding SVCall in the SoftDevice. There is no debug info for the softdevice image, so you would need to rely on the PC to see if it's in the SD's memory range.

RE: SAFERTOS+BLE

virendraVT — Thu, 28 Aug 2025 06:54:25 GMT

I did not face any issue with running freertos sample example from sdk, but when I ported the application to SAFERTOS I was facing error as seen in attached snapshot.

Also in the IAR, I have .intvec start @ 0x26000, ROM start @ 0x26000 end 0x7fffff and RAM start 0x2000986c and end as 0x2000ffff

RE: SAFERTOS+BLE

Vidar Berg — Thu, 28 Aug 2025 04:38:25 GMT

No worries. But are you not able to run or debug any of the BLE examples with your IAR setup? The softdevice function itself will not return a RAM address. Maybe you can post some screenshots showing the disassembly and CPU register view when stepping into and exiting the sd_softdevice_enable() function so I can try to look for clues for this behavior.

RE: SAFERTOS+BLE

virendraVT — Thu, 28 Aug 2025 00:55:58 GMT

Apologies for my delayed response. Currently the project I am using does not have a bootloader at the moment, as this is a POC to validate whether/how SAFERTOS+BLE works. I am able to debug the example `app_hrs_freertos` with or without this setting. In debugger mode, I can see that `ret_code = sd_softdevice_enable(&clock_lf_cfg, app_error_fault_handler);` in nrf_sdh.c returns some invalid address value and hence the application is unable to initialise.

RE: SAFERTOS+BLE

Vidar Berg — Mon, 18 Aug 2025 06:41:46 GMT

The purpose of setting --drv_vector_table_base to 0 is to ensure that the debugger does not start execution directly from the application's start address and skip the Softdevice initialization on boot. All IAR BLE projects in the SDK have this setting. Are you able to run and debug those?

[quote user="virendraVT"]The --drv_vector_table_base did not help as the debugger was not even triggering to main with this setting.[/quote]

Do you have a bootloader present on this device? Can you pause the debugger and check the program counter to see where it hangs?

RE: SAFERTOS+BLE

virendraVT — Mon, 11 Aug 2025 15:43:45 GMT

Hey Vidar

The --drv_vector_table_base did not help as the debugger was not even triggering to main with this setting. I was able to debug code further without this setting. However I am still facing error, 536901812 (0x200078B4) (earlier it was 536899764 (0x200070B4) )instead of success (0x0) from sd_softdevice_enable(&clock_lf_cfg, app_error_fault_handler)

RE: SAFERTOS+BLE

virendraVT — Wed, 06 Aug 2025 08:52:04 GMT

Thanks Vidar, I am using IAR 7 as of now but will keep this in mind. And will update --drv_vector_table_base once I fix another issue.
Thanks again.

RE: SAFERTOS+BLE

Vidar Berg — Tue, 05 Aug 2025 10:41:19 GMT

Please also make sure you have --drv_vector_table_base set to 0 in the IAR debugger settings as mentioned in this post RE: Warning: Stack pointer is setup to incorrect alignment. Stack addr = 0xFFFFFFFF

Same as in the SDK examples.

The SDK is also configured for IAR 7 and release notes mentions changes which may be neccessary if you're using IAR 8 or newer:

ote for IAR 8 users:

When using IAR 8, you must apply the following workaround in the MDK:

- Apply a patch to modules/nrfx/mdk/compiler_abstraction.h at line 140
(fix the '__ALIGN()' macro definition): use the argument 'n' in the macro expansion instead of 'x'.

-------------------

Libraries for IAR 8 require wchar_t to be of size 32 bits while IAR 7 requires 16 bits.

To run a project using IAR 8, follow these instructions:
1. Open the IAR project in IAR 8. The IAR workbench will automatically generate an IAR 8 compatible project file.
2. If the project contains one of the precompiled libraries listed below, replace it
with the IAR 8 compatible alternative (there are no projects targeting nRF51 in this SDK).
3. Save the project.
4. When building the project, you might get the warning: "The header file 'cmsis_iar.h' is obsolete and should not be used. [...]".
- The problem is described in DevZone post: https://devzone.nordicsemi.com/f/nordic-q-a/31123/iar-ewarm-8-22-1-complains-about-cmsis_iar-h
The solution is to remove all occurrences of #include <cmsis_iar.h>.

The affected libraries are:
- micro-ecc crypto:
- IAR7: Includes library located in the folder named “…_iar\…”.
- IAR8: Switch to using the library from the folder named “…_armgcc\…”.
- nrf_cc310, nrf_cc310_bl, and nrf_oberon:
- IAR7: Link to a library where “short_wchar” is part of the folder name.
- IAR8: Link to a library without “short_wchar” in the folder name.
- Gazell, NFC Tag, and 802.15.4:
- IAR7: Includes the library where the file name ends with “_iar”.
- IAR8: Switch to using the library with similar file name that ends with “_gcc”.

RE: SAFERTOS+BLE

virendraVT — Tue, 05 Aug 2025 04:29:30 GMT

Thanks Vidar,
This did help to recover the board.
I am still debugging the hardfault part.

RE: SAFERTOS+BLE

Vidar Berg — Fri, 01 Aug 2025 06:24:19 GMT

Hello,

The errors could indicate an unreliable connection between the debugger and the nRF52832. This can happen if the nRF is not properly powered. However, it is unusual to experience this on a development kit, and it doesn't make sense to me that you're able to both recover and load the firmware before the errors occur as the log shows.

Please try programming the hex file from the command line using nrfutil device (make sure it is up to date) to see if it makes any difference.

nrfutil device recover
nrfutil device program --firmware HEXFILE --options chip_erase_mode=ERASE_ALL,verify=VERIFY_READ,reset=RESET_SOFT

RE: SAFERTOS+BLE

virendraVT — Fri, 01 Aug 2025 02:33:40 GMT

Hi Vidar

Yes, I have the preprocessor `SOFTDEVICE_PRESENT` defined, also now I can't recover the development board even by using Programmer v4.6.2

The board is now continuously printing

<error> hardfault: HARD FAULT at 0x00031722
<error> hardfault: R0: 0x00004001 R1: 0x00000000 R2: 0x200078A8 R3: 0x00000000
<error> hardfault: R12: 0x00000000 LR: 0x0002E05D PSR: 0x21000000

And when I try to program another example from sdk nRF5 v17.1.0, I am getting below error log, and it seems I cannot recover this board.

10:30:13.816

Recovering Application core

10:30:13.816

Recovering Application core 0%

10:30:15.569

Recovering Application core 100%

10:30:15.570

Recovering Application core completed

10:30:15.570

Loading core information for Application core

10:30:15.571

Loading core information for Application core 0%

10:30:15.572

Update files regions according to Application core

10:30:15.572

Parse memory regions for file

10:30:15.572

SoftDevice detected, id 0x101 (S132 v7.2.0)

10:30:15.609

Failed "loading core information for application core". Error: code: 1, description: Generic, message: Batch task core-info failed, Device error: Failed to read from memory address 0x10000130: Failed to write DebugPort register 0x08: Unknown Error in J-Link DLL (error code =-1)

10:30:15.619

Error: Failed with exit code 1. One or more batch tasks failed: * 1050373515: Device error: Failed to read from memory address 0x10000130: Failed to write DebugPort register 0x08: Unknown Error in J-Link DLL (error code =-1) (Generic) Message: Batch task core-info failed, Device error: Failed to read from memory address 0x10000130: Failed to write DebugPort register 0x08: Unknown Error in J-Link DLL (error code =-1).

I would appreciate any help.
Thanks.

RE: SAFERTOS+BLE

Vidar Berg — Thu, 31 Jul 2025 11:03:59 GMT

Hello,

Are you able to pinpoint exactly where the fault exception is raised? I just had another ticket where the SVC instruction for sd_softdevice_enable() triggered a fault exception. The reason for this was that the CRITICAL_REGION_ENTER()/CRITICAL_REGION_EXIT() macros enclosing the call were compiled without the SOFTDEVICE_PRESENT symbol defined. Do you have this symbol included in your preprocessor definitions like in the ble_app_hrs_freertos example?

Best regards,

Vidar