This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Question about SVCALL in ble_gap.h

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?

Parents
  • 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.

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

Reply
  • 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.

Children
No Data
Related