This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

Yet another sd_softdevice_enable sv exception & halt issue on nrf52832

am using a ultra-miniature (BMD-350) series module from Rigdo which has the nRF52832 BLE SoC. It is placed on a custom board such that all pins from the nrf52 SoC are brought out on a female headers. There is no external crystal on the board.

Firmware/SDK configuration:

  • nRF5_SDK_15.3.0_59ac345 SDK
  • pca10040 and softdevice s132  
  • nrf52832_xxaa

Debugger

  • J-Link EDU Mini debug module and using Segger Ozone v2.62c and Jlink (v6.46c) software for debugging.

IDE

  • IAR Embedded Workbench 8.32.1

Few weeks back I had extensively tested several softdevice based examples from the SDK particularly ble_app_uart on our custom PCB and everything was working. 

However suddenly today the examples stopped working even though using the same hardware board. The problem occurs while initializing the BLE stack where in a call to function sd_softdevice_enable is made to enable the softdevice. However the function never returns ( any error code ) and seems to be halted at an sv call to #16 (in assembly, this is a branch instruction to address 00002DD6 at PC with address 00002DD6). Below are two debug screenshots from Ozone which display the problem. 

First screenshot just before the svc call is made.

 First screenshot just before the svc call is made

Second screenshot just after the svc call is made (step over resulting in halt). 

 second screenshot just after the svc call is made (step over resulting in halt)

The corresponding segger jlink command log for above debug screenshots while stepping through code from Ozone console is as follows:

Debug.Start();
Device "NRF52832_XXAA" selected.
Found SW-DP with ID 0x2BA01477
Found SW-DP with ID 0x2BA01477
Scanning AP map to find all available APs
AP[2]: Stopped AP scan as end of AP map has been reached
AP[0]: AHB-AP (IDR: 0x24770011)
AP[1]: JTAG-AP (IDR: 0x02880000)
Iterating through AP map to find AHB-AP to use
AP[0]: Core found
AP[0]: AHB-AP ROM base: 0xE00FF000
CPUID register: 0x410FC241. Implementer code: 0x41 (ARM)
Found Cortex-M4 r0p1, Little endian.
FPUnit: 6 code (BP) slots and 2 literal slots
CoreSight components:
ROMTbl[0] @ E00FF000
ROMTbl[0][0]: E000E000, CID: B105E00D, PID: 000BB00C SCS-M7
ROMTbl[0][1]: E0001000, CID: B105E00D, PID: 003BB002 DWT
ROMTbl[0][2]: E0002000, CID: B105E00D, PID: 002BB003 FPB
ROMTbl[0][3]: E0000000, CID: B105E00D, PID: 003BB001 ITM
ROMTbl[0][4]: E0040000, CID: B105900D, PID: 000BB9A1 TPIU
ROMTbl[0][5]: E0041000, CID: B105900D, PID: 000BB925 ETM
J-Link: connected to target device
Reset: Halt core after reset via DEMCR.VC_CORERESET.
Reset: Reset device via AIRCR.SYSRESETREQ.
Elf.GetBaseAddr();
Target.SetReg ("SP", 0x20005EF8);
Target.SetReg ("PC", 0x2F53D);
J-Link: Flash download: Bank 0 @ 0x00000000: Skipped. Contents already match
Elf.GetBaseAddr();
Target.SetReg ("SP", 0x20005EF8);
Target.SetReg ("PC", 0x2F53D);
Executed J-Link command "SetRTTAddr 0x2000354C"
Debug.Continue();
Debug.Continue();

I have seen atleast dozen posts related to similar problem on this forum, but most of them are not working for me. Here is what I have tried so far to troubleshoot this problem:

  1. As our custom board doesn't have an external oscillator. Suggestions related to LF Clock configuration were already incorporated in code weeks back when softdevice based examples were running on our board, such as modifying sdk_config.h file to use internal RC oscillator as LF clock source, with 500 PPM accuracy, etc. https://devzone.nordicsemi.com/f/nordic-q-a/44807/hangs-on-sd_softdevice_enable/177672#177672                                                               
    // </h> 
    //==========================================================
    
    // <h> Clock - SoftDevice clock configuration
    
    //==========================================================
    // <o> NRF_SDH_CLOCK_LF_SRC  - SoftDevice clock source.
     
    // <0=> NRF_CLOCK_LF_SRC_RC 
    // <1=> NRF_CLOCK_LF_SRC_XTAL 
    // <2=> NRF_CLOCK_LF_SRC_SYNTH 
    
    #ifndef NRF_SDH_CLOCK_LF_SRC
    //#define NRF_SDH_CLOCK_LF_SRC 1
    #define NRF_SDH_CLOCK_LF_SRC 0 //DGS
    #endif
    
    // <o> NRF_SDH_CLOCK_LF_RC_CTIV - SoftDevice calibration timer interval. 
    #ifndef NRF_SDH_CLOCK_LF_RC_CTIV
    // #define NRF_SDH_CLOCK_LF_RC_CTIV 0  
    #define NRF_SDH_CLOCK_LF_RC_CTIV 16 //DGS
    #endif
    
    // <o> NRF_SDH_CLOCK_LF_RC_TEMP_CTIV - SoftDevice calibration timer interval under constant temperature. 
    // <i> How often (in number of calibration intervals) the RC oscillator shall be calibrated
    // <i>  if the temperature has not changed.
    
    #ifndef NRF_SDH_CLOCK_LF_RC_TEMP_CTIV
    // #define NRF_SDH_CLOCK_LF_RC_TEMP_CTIV 0
    #define NRF_SDH_CLOCK_LF_RC_TEMP_CTIV 2 //DGS
    #endif
    
    // <o> NRF_SDH_CLOCK_LF_ACCURACY  - External clock accuracy used in the LL to compute timing.
     
    // <0=> NRF_CLOCK_LF_ACCURACY_250_PPM 
    // <1=> NRF_CLOCK_LF_ACCURACY_500_PPM 
    // <2=> NRF_CLOCK_LF_ACCURACY_150_PPM 
    // <3=> NRF_CLOCK_LF_ACCURACY_100_PPM 
    // <4=> NRF_CLOCK_LF_ACCURACY_75_PPM 
    // <5=> NRF_CLOCK_LF_ACCURACY_50_PPM 
    // <6=> NRF_CLOCK_LF_ACCURACY_30_PPM 
    // <7=> NRF_CLOCK_LF_ACCURACY_20_PPM 
    // <8=> NRF_CLOCK_LF_ACCURACY_10_PPM 
    // <9=> NRF_CLOCK_LF_ACCURACY_5_PPM 
    // <10=> NRF_CLOCK_LF_ACCURACY_2_PPM 
    // <11=> NRF_CLOCK_LF_ACCURACY_1_PPM 
    
    #ifndef NRF_SDH_CLOCK_LF_ACCURACY
    // #define NRF_SDH_CLOCK_LF_ACCURACY 7
    #define NRF_SDH_CLOCK_LF_ACCURACY 1 //DGS
    #endif
    
    // </h> 
  2. To be sure that nothing broke in the board or jlink connection, I tried spi slave example from the sdk which doesn't use softdevice and it worked like before. 
  3. It also seemed like it could have been a software/tool IAR issue, perhaps something got updated recently in software/driver/settings which broke things, so we went about installing IAR/Segger tools on another machine, but upon compiling and flashing, still no softdevice based example would run on our pcb. So it seems updates in tool/software doesn't seem to have caused this problem.
  4. I also checked to see if this problem occurs if I flash the ble_uart_app but donot attach my debugger to it. However, using nRFConnect app, I never see the nordic uart ble device in list of available bluetooth devices, which implies the app halts (sv call exception) and never reaches a point where the ble can advertise.
  5. Tried nrf command line utility nrfjporg to verify if device is being flashed correctly (suggested in https://devzone.nordicsemi.com/f/nordic-q-a/25251/halting-at-svcall-sd_softdevice_enable)

C:\Program Files\Nordic Semiconductor\nrf-command-line-tools\bin>nrfjprog.exe -e
Erasing user available code and UICR flash areas.
Applying system reset.

C:\Program Files\Nordic Semiconductor\nrf-command-line-tools\bin>nrfjprog.exe --program "D:\github\bmnl\SDK\nRF5_SDK_15.3.0_59ac345\examples\ble_peripheral\ble_app_uart\pca10040\s132\iar\_build\ble_app_uart_pca10040_s132.hex" --verify
Parsing hex file.
Reading flash area to program to guarantee it is erased.
Checking that the area to write is not protected.
Programming device.
Verifying programming.
Verified OK.

As of now I donot know how to make this work. I have already read through multiple posts but nothing seems to make it work. I would appreciate any support to help resolve this issue. 

Parents
  • Hi,

    Looks like the data at address 0x0 may have been overwritten. The first word should for instance have been 0x20000400 (initial stack pointer), not  0x20002890 as shown in Ozone. Try to re-program the Softdevice with nrfjprog and see if you run into the same problem.

    e.g.,

    1. nrfjprog --program <sdk>/components/softdevice/s132/hex/s132_nrf52_6.1.1_softdevice.hex --sectorerase -r

    2. nrfjprog --readregs // prints out CPU registers so you can check if the PC is stuck at 0x2DD6

Reply
  • Hi,

    Looks like the data at address 0x0 may have been overwritten. The first word should for instance have been 0x20000400 (initial stack pointer), not  0x20002890 as shown in Ozone. Try to re-program the Softdevice with nrfjprog and see if you run into the same problem.

    e.g.,

    1. nrfjprog --program <sdk>/components/softdevice/s132/hex/s132_nrf52_6.1.1_softdevice.hex --sectorerase -r

    2. nrfjprog --readregs // prints out CPU registers so you can check if the PC is stuck at 0x2DD6

Children
No Data
Related