Bond DB回调覆盖

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.

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.

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.

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.

致以最诚挚的问候，

MKE公司