Using NFC with SDK12 on nRF52832

[Jarmo]

The NFC example (launch app) on SDK12 does work on my device. However, when I copy exactly the same code into my own project, the NFC does not work. The difference is that I have S132 soft device flashed, but that does not explain the problem, because I was able to add soft device into the SDK example, and it continued working.

My question is: what are the critical things for NFC to work? For example, do I need to set some specific flags into sdk_config.h? In an earlier question here, concerning SDK11, there was a conclusion that CLOCK_ENABLED must be set for NFC to work. But this is already set on my project, so maybe there is some other hidden thing missing? Wrong clock frequency somewhere? I/O configuration flags? Any ideas what I could try?

[Jarmo]

It was some of the Makefile CFLAGS definitions. I copied the flags from the NFC example into my project, and removed the ones that were in my project previously, and got it finally working. I don't know exactly the flag(s) that really did it.

What are those strange PAN-flags, such as NRF52_PAN_4? Is there a list of them somewhere? I guess PAN does not mean Personal Area Network in this case... :P

(Apologies, but I am once again so frustrated that I have to say you at Nordic Semiconductor have made a very nice minefields into your SDK. And all those drv_, app_, hal_* and what-not code groups seem to make little or no sense for me, I feel like there's no clear system ideas behind.)

[bjorn-spockeli]

The PANs refers to the Product Anomaly Notice for the nRF52(now renamed to Errata), i.e. known issues with chip. You can find the Errata here on Infocenter. I do understand the frustration and I admit that some parts of our SKD are not intuitive enough. We are grateful for all feedback on the SDK so that can improve it.

The hal_, drv_ and app_* -layers provide different level of abstraction for the user of the SDK. The hardware access layer (HAL) provides basic APIs for accessing the registers of the hardware peripherals, the driver layer provides APIs on a higher level than the HAL and the app_- libraries provides APIs on a higher level than the driver again.

[Jarmo]

Thanks for commenting! Okay, hal-drv-app -hierarchy sounds nice, but the problem is that for an application programmer it is not so clear which API should be used for a particular purpose. Yes, lack of intuitivity, lack of self-descriptiveness, that is true. For example, using clear descriptive words instead of three-letter acronyms, starting from files naming would make things a bit better. First days with nRF SDK I just spent wondering what the heck are those bas, dis, hrs etc. things. Luckily some development seem to be happened since then, many of your new files have almost understandable names.

[bjorn-spockeli]

I guess it will depend on which functionalities that are required, the app_-libraries are meant to be easy to use and configure, and will be enough for simple use cases. For more complex use-cases I would recommend using the drivers as they give you more control over the peripheral. If you find that the driver does not provide the functionalities/features that you neddd then you can create your own driver with the HAL.

Glad to hear that we're moving in the right direction. I will pass on your feedback to the SDK developers.

[Jarmo]

Thanks, I look forward getting more easy SDK's from Nordic Semiconductor in the future! Maybe some day I can write a bluetooth beacon with a nice C++ API just with a few lines of code, like:

main()
{
  BleBeacon myBeacon("EasyBeacon");
  myBeacon.setScanResponseData("scan response");
  myBeacon.startAdvertising(100); // interval in ms
  runSystem();
}

...instead of tuning something like 900 lines of code, like you are providing it currently. It shouldn't be that complicated, really.