SAFERTOS+BLE

[virendraVT]

I have been trying to make SAFERTOS based BLE example working on nRF52832 (PCA10040) similar to the one provided by Nordic SDK 17.1.0 at `examples\ble_peripheral\ble_app_hrs_freertos`

I had taken the SAFERTOS evaluation example as base and tried to enable BLE as shown in the freertos example. I had created SAFERTOS versions of files/code where FREERTOS functions were getting used (nrf_sdh_freertos.c, app_timer_freertos.c) and updated timer and task creation.

I also fixed the IAR settings to include softdevice and changed the icf to get correct ram and rom addresses and included preprocessor defined symbols.

However, I was still getting a hardfault during initialization of softdevice. The application code is giving error code `536899764 (0x200070B4) ` instead of success (0x0) from sd_softdevice_enable(&clock_lf_cfg, app_error_fault_handler).

As Nordic doesn't provide source for softdevice I am unable to debug this.

Can anyone help/point to right resources on what am I doing wrong or what should I check to fix this issue.

I would appreciate any help.

Thanks.

[Vidar Berg]

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

[virendraVT]

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.

[Vidar Berg]

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

[virendraVT]

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

[Vidar Berg]

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”.