Question about SVCALL in ble_gap.h

[Michael]

I'm trying to follow the code from one of your examples, specifically ble_beacon in SDK 8.0 and eventually I get to a point where I'm not sure what's going on so I figured I'd ask a question about it. I have knowledge in object oriented programming but am still getting familiarized with BLE.

I started my trace from the "static void advertising_start(void)" function in main.c and was tracing "sd_ble_gap_adv_start" from the line: "err_code = sd_ble_gap_adv_start(&m_adv_params);"

this took me to the ble_gap.h header file where the function/service is mentioned twice:

enum BLE_GAP_SVCS { ..... SD_BLE_GAP_ADV_START, ..... };

and

SVCALL(SD_BLE_GAP_ADV_START, uint32_t, sd_ble_gap_adv_start(ble_gap_adv_params_t const *p_adv_params));

This is a specific example but in general I'm not sure what is going on in the codebase in circumstances such as this. Should there be a ble_gap.c file included in the project? Does this have something to do with the GAP from BLE? Is there something simple I'm missing?

[RK]

This is how the application communicates with the softdevice. The SVC calls (each of which has a different number) trigger the SVC IRQ handler which the softdevice implements and performs the requested action. This is why you don't have to link with the softdevice, there's nothing to link with, the entire communication between the two is done with SVC calls. That's also why there's no .c file, there's no C, apart from the SVCALL() macro which expands into 2 lines of assembler which call the SVC call with the correct number and return.

[Susheel Nuguru]

I will just add a line to RK;s explanation. The reason you cannot see anything in trace is because softdevice is built with no debug info and the SVC call just jumps into softdevice address space, so debugger is clueless about what is happening. This is intentional from Nordic as we do not want applications to know too much of what is happening inside softdevice.

[Michael]

Thank you both for the explanation, that makes sense to hide the IP of the softdevice. Is all the available documentation about this provided in the html files of the SDK or is there somewhere else I can look for more information?

[RK]

Nothing to do with hiding the IP of the softdevice, it's a very good way however to have a softdevice and a main piece of user code existing on the chip running fairly independently with a well-defined interface between them. Using SVC calls is a technique often used in other similar situations like some RTOS implementations. Because it's interrupt-based it's easy to manage priorities as well.

Other implementations link with a library and load that on with the code, also works fine, however code needs to be recompiled for every library change. With the interface being solely based on a few service calls and some defined structs, there's no such problem and you can often switch between softdevices of the same major release without even recompiling.

Yes all the documentation is in the html files, there's loads.