cancel
Showing results for 
Search instead for 
Did you mean: 

WICED Smart Bluetooth

Anonymous
Not applicable

Hi, I'm attempting to write a large struct to NVRAM using a BCM20732 SPIL dev board.  It seems that the function bleprofile_WriteNVRAM always fails (returns 0) on the second write.

Also, bleprofile_WriteNVRAM returns 0 when I try to write more than 220 bytes.  I thought the limit was 255.  I'm not sure if these issues are due to using the SPIL board vs the TAG board.

Here's the code to write to NVRam:

uint8 writeNVRam(NVRamType * nvRam){

  uint16 totalWritten = 0;

  uint8 nvOffset = 0;

  ble_traceprintf("Writing size %d\r", sizeof(NVRamType));


  while(totalWritten < sizeof(NVRamType)){

  bleprofile_DeleteNVRAM(NV_APP_LOCATION - nvOffset);


  ble_traceprintf("Writing location %X with %d bytes from %X.\r",

  NV_APP_LOCATION - nvOffset,

  MIN(sizeof(NVRamType) - totalWritten, NV_LOCATION_SIZE),

  &(((uint8*)nvRam)[totalWritten]));

  uint8 nWritten = bleprofile_WriteNVRAM(NV_APP_LOCATION - nvOffset,

  MIN(sizeof(NVRamType) - totalWritten, NV_LOCATION_SIZE),

  &(((uint8*)nvRam)[totalWritten]));

  ble_traceprintf("Wrote %d bytes.\r", nWritten);

  if(nWritten == 0)

  return SE_NV_WRITE_FAILED;

  totalWritten += nWritten;

  ++nvOffset;

  }

  return SE_OK;

}



This produces the following output to console:

Writing location 6F with 220 bytes from 20A590.

Wrote 220 bytes.

Writing location 6E with 63 bytes from 20A66C.

Wrote 0 bytes.


Thank you for your attention.

0 Likes
Reply
1 Solution
Employee

From ws_upgrade.c in [uart|ota]_firmware_upgrade sample app from SDK 2.0.1, the layout of EEPROM is:

pastedImage_0.png

When you read/write/delete NV items using bleprofile_*NVRAM, these operations are performed in the section marked VS1 in the picture above. The stack uses some of this for some internal book-keeping. When you pair, all pairing information is stored in this area too. So it is possible that you ran out of space when you attempted to store the 63 remaining bytes. You can increase the the space allocated for VS1 by changing a couple of options in <SDK>/Platforms/BCM92073?TAG_Q32/2073?_EEPROM*.btp (? here is 2 in SDK 1.1.0 and either 6 or 7 in SDK 2.0.1 based on whichever you are using):

DLConfigVSLength = 1024

ConfigDSLocation = 1408

(The actual values could be different from these). Note that if you increase DLConfigVSLength, you may have to also increase ConfigDSLocation (which is the same as DS1 in the picture above) so that there is no overlap (the hex file conversion step when building will fail if it detects an overlap between the two regions).

View solution in original post

2 Replies
Employee

The log seems to believe it wrote the 220 bytes.  If you read them back, are they what you expect? 


0 Likes
Reply
Employee

From ws_upgrade.c in [uart|ota]_firmware_upgrade sample app from SDK 2.0.1, the layout of EEPROM is:

pastedImage_0.png

When you read/write/delete NV items using bleprofile_*NVRAM, these operations are performed in the section marked VS1 in the picture above. The stack uses some of this for some internal book-keeping. When you pair, all pairing information is stored in this area too. So it is possible that you ran out of space when you attempted to store the 63 remaining bytes. You can increase the the space allocated for VS1 by changing a couple of options in <SDK>/Platforms/BCM92073?TAG_Q32/2073?_EEPROM*.btp (? here is 2 in SDK 1.1.0 and either 6 or 7 in SDK 2.0.1 based on whichever you are using):

DLConfigVSLength = 1024

ConfigDSLocation = 1408

(The actual values could be different from these). Note that if you increase DLConfigVSLength, you may have to also increase ConfigDSLocation (which is the same as DS1 in the picture above) so that there is no overlap (the hex file conversion step when building will fail if it detects an overlap between the two regions).

View solution in original post