Porting Peer manager or How to do bonding

[sveenman]

Firstly my current usecase:

We are using a STM32 as a main processor. the STM uses UART to communicate with the nRF52 using the serialization stuff. I currently have most of it working and ported. I can use the hrs example, connect to the Nordic_HRM and get heartrate measurements. This does not include bonding and pairing though.

What i want:
I want to be able to start a pairing and bonding procedure from the STM using the serialization. 

The problem:

The bonding and pairing is handeled by the peer manager and corresponding files on the nRF52 library. These files use A LOT of internal nRF parts. including atommic functions, queues flash stoage, crypto etc. And consist of a lot and a lot of files. I am trying to get this to work under the STM but can't even get it to compile. It also uses the nRF flash storage to save bonding information. I dont mind writing my own stuff for this ofcourse and eventually we will need to safe this bonding information on the SD card connected to the STM.

I would like a pointer where to start with porting this managing of peers or how to do pairing and bonding without these libraries, what information needs to be send, the events etc. 

Ideally i would have all the parts that are needed for bonding so that i have the most control over the flow on the STM and saving information etc.

[Hung Bui]

Hi Sveenman, 

Porting the peer manager can be a challenging job, it's one of the biggest module we have in the SDK. 

But I don't see any hard blocker that would stop you from porting the module to STM32. 

Regarding your question, I would suggest having a look at these message sequence charts here. It should cover most of the situations regarding BLE bonding/pairing. 

[misaka]

hi Sveenman have you got it already, i'm getting involved with this issue currently, hope you can share your thought for reference.

[sveenman]

Trying to port this library got me into a whole lot of issues, with my limited understanding of the internals of the library (what part was nrf52 BLE code, and what part was application code etc). So we have decided to take a different approach. We got the secure bootloader on so now we have developed our own communication between the nrf52 and the STM32 with our own communication library. This offloads all BLE specific implementations to the nrf52 and allows our STM32 to only do application code. (adding filters, whitelistst, deleting bonds etc) 

from our STM we can now flash new firmware through this bootloader so we always have the option to add more communication on the NRF52 when needed.

[misaka]

Thanks Sveenman. I didn't expect you to reply so quickly, what a surprise.

as far as I can see there's only two parts need to be reimplement, one is flash operation, provide read/write basic functions, the other is select available crypto as backend, I'm considering software crypto can be used. are you saying those things would bought a lot of issues?

[sveenman]

I don't think there is anything theoretically stopping the port. I came into this with limited knowledge of BLE, the NRF52 and the framework. I already struggled to get the basic serialization compiled within our exisiting project. Getting all the framework files out of the delivered examples was a struggle for me. Maybe i was missing something here which could cause this step to be a lot easier. But taking over files i basically got 10+ errors per file, which first had to be resolved before any porting could begin. This caused me to have no clue wether each error was because i just needed to change some minor names/functions etc, or if i actually needed to port something, or if the part i copied was actually part of the internal software. 

Creating our own BLE specific firmware actually worked out well for us in the end, it allowed us to offload a lot of the BLE work to the nrf52 so our main processor doesn't care about it. Because we can flash new firmware from our main processor this means any missing implementations can easily be added.

[misaka]

correctly. I have fixed all compile errors to let the serialization runs in our host. The basic BLE operation such as find the advertisement, establish BLE connection can be successfully performed. So this is the problem, I have two solutions currently, 1. port peer_manager in serialization system 2. offload the application down to BLE chip, create a custom transport to transfer the application specific data. But I just don't know how much effort would I take with these two solutions, also the prods and cons. 

[misaka]

do you have a most common used email, so I can talk to you through it, thanks.

[sveenman]

Sorry, i wont share my email on this forum post

I think you are basically at the same position i was in when creating this forum thread. For me trying to spend more time into the serialization framework after fixing all the issues i had faced didnt seem like a good solution. Even if i would get bonding to work it might have been short lived until the next problem. Creating an own communication library made all nordic BLE parts work flawlessly. Creating and setting up this communication can take a bit of thinking, and every new functionality will need to be created manually, but this only takes a few minutes per BLE function, and only needs to be done once. 

one requirement for this to work in a production setting is that you need to have the bootloader working and be able to flash new firmware from the main processor. In a dev environment this might be less needed but still possibly a very nice to have. 

For the communication i reused a lot of their serialization as that was already working anyway. This allows me to create functions that can be called through the serialization layer and i just have to provide my own implementations. A lot of the functions just call a nordic BLE function 1:1. But because of this the full nrf52 framework is running in the background, so this is able to handle all the bonding. 

[misaka]

thanks. what you said helps me a lot. may be I should have a break and think more to determine the final solution.