2 years ago
Bond DB callback overrides
Posted bymkelwood0 points 8 repliesThe SDK provides callbacks for the application bond database functions, which can be replaced with user functions. However, the struct bond_db is defined in the app_bond_db.c file (not in the header) and the bond_db declaration is static in app_bond_db.c, so it is very difficult to provide meaningful user-defined replacements for the app_bond_db_callbacks without modifying the SDK files. I try not do do this because it makes upgrading the SDK very difficult when custom modifications have been made.
Our application will store the bond DB in the flash memory of another processor in the design, so the canned SPI_FLASH and I2C_EEPROM functions are not suitable. It would be really nice if the SDK provided a function to retrieve the bond_db structure address and size, which would allow override of the default callbacks without modifying the SDK. As it is now, I will need to modify the SDK to provide this function.
2 years ago
Hi mkelwood,
你能试着解释一点什么哟u would like to accomplish? If I am able to understand from your thread, that you want to accomplish is to start reading the bonding data but you want to start the procedure before the procedure is not finished? And when the bonding procedure has been finished, a callback should be triggered? Please, provide as further clarification on that.
Thanks, PM_Dialog
2 years ago
Hello PM_Dialog,
That's roughly correct. The problem is that I will either need to return from app_bdb_init() before the bond database is retrieved, or block in app_bdb_init() while calling the scheduler to allow the SPI bus processing in the user_on_system_powered() callback to continue, similar to what is done in bond_db_erase_flash_sectors(). In the first case I would populate the bond_db structure either by message handling or directly in the SPI processing code once the bond database was retrieved from the other processor. This case is easier to implement, but it may be dangerous to return from app_dbd_init() without a valid bond database in place. The second case (block and call scheduler from within app_dbd_init()) may be safer but is more difficult to implement correctly, and it will only work if the rwip_schedule() call will allow the SPI processing to continue by calling user_on_system_powered() as needed.
So my question is (A) is it safe to return from app_bdb_init() and proceed with the application startup before the bond database is available, and if not, then (B) will the block-and-schedule scheme work by calling user_on_system_powered() as needed until the bond database is received?
Also, per my first post, since the bond database load and store mechanisms are not hooked to app_bond_db_callbacks, I have no choice but to modify the SDK to implement custom load and store mechanisms, which is unfortunate.
2 years ago
Hi mkelwood,
Thanks for your information. I will check your issue and I will let you know shortly.
Thanks, PM_Dialog
2 years ago
Hello PM_Dialog,
I implemented Scheme A above: proceed from app_bdb_init() with an invalid database and back-fill the bond database after it is retrieved from other processor. This seems to work properly. I suppose there is a small window where a pairing event could occur without a valid database in place (any modifications would get over-written), but I estimate that the whole process is complete before the first advertise packet even goes out on the radio. In any case we will probably have to live with that risk.
It would be nice to get confirmation that this scheme does not have other (unknown to me) caveats. Any information you can provide would be appreciated.
2 years ago
Hi mkelwood,
Apologies for the delay and thanks for the procedure you have provided. Could you please clarify if this procedure fixes your issue? As you mentioned you SDK modify the SDK (I would not recommend it), but I don’t have any news on this.
Thanks, PM_Dialog
2 years ago
Hi PM_Dialog,
The described procedure seems to be working fine for us. I closed the window by delaying the start of advertising until the bond database was retrieved and in place, so there should be no possibility of a connection attempt with an invalid database. This procedure does require changes to the SDK in app_bond_db.c. I agree that this is unfortunate, but the published callback structure for the bond database does not support implementation of a custom storage method for the bond database (which was the reason for my original post here). I hope the development team will rectify this at some point.
With best regards,
MKE
2 years ago
As a followup to my first post, is there a good way to handle retrieval of the bond database "asynchronously"? For example, as mentioned our system will store the bond database in a separate processor. So when it is time to initialize the bond db, the DA14585 will request (via SPI bus) transfer of the bond db from the other processor; the actual transfer will complete some time later. The SPI processing is handled via callback (specifically during the user_on_system_powered() callback), so I can't just block the app_bdb_init() call while I wait for this transfer to take place.
I could just return from the app_bdb_init() function and "backfill" the bond db when it has been received, but I fear this could cause other problems. Any suggestions on handling this situation? Thanks.