PDS Vs EEPROM with BLuSDK6.2 in ASF3.40

Go To Last Post
3 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi All.

I have a complicated project using SAMD21J18A MCU and BTLC1000-ZR BLE module.

My project uses EEPROM, via the ASF EEPROM emulation, for some non Bluetooth related parameters.

I just updated my project to  ASF3.40 to get BluSDK6.2 which promises NVM storage of BLE bonding info so it does not forget the bonding every time the power cycles.

However I am having trouble getting this to work.

BluSDK6.2 uses the PDS (persistent data storage) service (rather than the EEPROM emulation service) to store the bonding info in the NVM(flash).

However when I updated my project using the ASF Wizzard the PDS files were not included in the project.

To try to get it to work I downloaded the ASF3.40 stand alone download and copied the PDS files into my project.

Now it compiles OK but PDS will not initialise successfully.

I have set the EEPROM fuses to allocate the maximum 16K of flash space to EEPROM.

So can the PDS and EEPROM emulation services co-exist?

If so how can I configure it so they share the available EEPROM emulation space in flash?

Or is there some trick I am missing to get this to work?

 

Thanks for any guidance you can give.

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Is their a user's guide for the PDS service?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I found what seems like a bug in the ASF file pds.c.

in function pds_delete_all() on line 549 =

    Assert((pds_init_status != false));

This ASSERT fails on the initial run.

This function is called from pds_nvm_init() when pds_init_status == false initially, so the ASSERT fails.

I commented out the ASSERT on line 549 and it seems to work.

I can now bond my device and phone by enterring the BLE pass key.

Then I can turn off the device and the phone, turn them on again and reconnect without having to reenter the pass key.

So it looks like it is successfully remembering the bonding info in the nvm.

 

I have yet to check if it conflicts with the existing EEPROM emulation use...

I think I might have to jimmy the EEPROM service to use the top 1K of EEPROM space, even though I changed the fuses to allocate 16K?

Does anyone have experience of using both PDS and EEPROM emulation together?

The PDS seems to be hardcoded to use the address of the start of the 16K allocation so the fuses have to be set for that.

In conf_nvm.h line 44:

#define PDS_START_ADDRESS        0x003C000