Halting at SVCall(SD_SOFTDEVICE_ENABLE, ...)

[cswanson420]

Hi,

I'm trying to write unit tests and have arrived at the point to write tests for ble characteristic addition to a service.

To offer some background, I have written a test harness called Yoke that will flash an Intel Hex file to a nRF52832 device that has been compiled with unit tests written using the Unity C framework. The hex file will output test results to the UART peripheral that Yoke receives to present the results on a web page. Having just written this framework, I have had very good success integrating the SPI peripheral into my project.

The challenge now is integrating the soft device into the test harness. Borrowing heavily from the ble_peripheral examples, I can compile a unit test to add a characteristic to a service and run assertions on whether the set_value, get value calls return the expected value.

My problem - which is the focus of this question - is the code execution halts at SVCall(SD_SOFTDEVICE_ENABLE, ...) as presented by Segger's Ozone utility. Indeed, Ozone seems to indicate that although subsequent "step" commands are issued, the PC register does not advance. Having the CPU continue from this point and issuing a subsequent "halt" leaves the PC precisely where is was before.

Initially, I was not flashing the softdevice, but I have recently accommodated this concern and I still have the same behaviour.

Therefore, I am impressed I am missing some Makefile entry or some other aspect that will properly execute the SVCall.

I have included a screen shot of the Ozone information that, hopefully, may help indicate what I may be missing.

Screen Shot 2017-09-17 at 1.11.39 PM.png

Thanks

notes.jlinkscript.20170925.001.txt

Makefile

[bjorn-spockeli]

Which SDK version and which S132 version are you using? As stated in the briefsd_softdevice_enable() should return an error code if the SoftDevice cannot be enabled. Are you using one of the make file that is supplied with SDK as a template?

[cswanson420]

I am using SDK 11.0.0 and Soft Device S132 Version 2.0. I am using a Makefile from a peripheral example for the unit tests which leaves out the support for the Softdevice as comparing to a Makefile from ble_peripheral example directories. Therefore, I am now trying to patch these differences as certain -D options include softdevice functionality when defined.

To answer your question about the sd_softdevice_enable return code, I have not arrived at this point because the SVCall occurs before the function can return.

I feel I am missing a critical element that populates the SVCall handler correctly and I was hoping the solution was as obvious as "add the -DXCYABC option to CFLAGS".

Although, this still may be true, I am very impressed with the tenacity and focus Nordic gives from their support staff and we shall arrive with a deeper understanding shortly.

[bjorn-spockeli]

Are you positive that the SoftDevice is present? If the PC does not change after you execute the SV Call then it could sound like the SD is missing. At which address does the PC halt after you execute the SVCall? Also could you attach your Makefile ?

[cswanson420]

Hi, the device is stuck at address: 0000 4492 SVC_Handler. I used a JLinkEXE script to flash both the SD and my app code. I'll attach both the script output and the Makefile.

Just to be sure, is there a means to inspect that the SD was flashed properly?

[bjorn-spockeli]

Can't really see anything in your makefile that should cause SV calls to not properly execute. Have you tried flashing the softdevice using nrfjprog? The nrfjprog --verify option will readback the flash and compare it to the hexfile. Usage nrfjprog --program hexfile.hex --verify Are you able to run an unmodified ble_peripheral example from the SDK on you device?