• State Verified Answer
  • Replies 6 replies
  • Subscribers 67 subscribers
  • Views 5146 views
  • Users 0 members are here
Attachments (0)
Nordic Case Info
  • Case ID: 125250
Options
This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

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

Parents
  • 0

    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.

Reply
  • 0

    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.

Children
No Data
Related