Does NVRAM keep state after power is removed? (BCM20732S)

Tip / Sign in to post questions, reply, level up, and achieve exciting badges. Know more

cross mob
legic_1490776
Level 5
Level 5
25 likes received 10 likes received First like received

I had been assuming that NVRAM was resident in EEPROM, and thus would persist after power is removed from the system.

Is this correct, or does it get cleared when power is removed completely (vs just going to HIDoff)?

From what I can see it seems to get cleared.

1 Solution
ShawnA_01
Employee
Employee
10 questions asked 5 comments on KBA First comment on KBA

The BCM20732S module has 64kbytes of EEPROM on-board.  (so does its brethren the 20736/7S)

Its contents are not supposed to get cleared on either power-down, nor entering of HIDOFF.

By "cleared", do you mean, cleared-cleared, as in:  All reads return values of 0x00, or 0xFF.... or do you mean "cleared' in that the contents are now scrambled and not what you expected? 

Is it possible your application is writing to addresses beyond the end of the device and "wrapping around" to the addresses in the beginning?

Are you using OTA upgrade feature?

Note: There were very early versions of the module that only have 32kbytes of EEPROM, but no customers were ever supposed to have them. The SB02 was superseded in 4Q 2013 so you probably don't have one.

Just some ideas, and of course-all the usual questions apply:   When did this problem start, does it happen on all boards, how can we reproduce it, yada-yada....  🙂

View solution in original post

0 Likes
10 Replies
ShawnA_01
Employee
Employee
10 questions asked 5 comments on KBA First comment on KBA

The BCM20732S module has 64kbytes of EEPROM on-board.  (so does its brethren the 20736/7S)

Its contents are not supposed to get cleared on either power-down, nor entering of HIDOFF.

By "cleared", do you mean, cleared-cleared, as in:  All reads return values of 0x00, or 0xFF.... or do you mean "cleared' in that the contents are now scrambled and not what you expected? 

Is it possible your application is writing to addresses beyond the end of the device and "wrapping around" to the addresses in the beginning?

Are you using OTA upgrade feature?

Note: There were very early versions of the module that only have 32kbytes of EEPROM, but no customers were ever supposed to have them. The SB02 was superseded in 4Q 2013 so you probably don't have one.

Just some ideas, and of course-all the usual questions apply:   When did this problem start, does it happen on all boards, how can we reproduce it, yada-yada....  🙂

0 Likes

The BCM20732S module has 64kbytes of EEPROM on-board.  (so does its brethren the 20736/7S)

Its contents are not supposed to get cleared on either power-down, nor entering of HIDOFF.

I am talking about the use of the function bleprofile_ReadNVRAM and WriteNVRAM.

The application and so on survive removing the battery power.  Stuff I write using WriteNVRAM survives HIDoff and reset, but does not seem to survive removing power from the system.

I was assuming those functions wrote the data to EEPROM, but perhaps not?

By "cleared", do you mean, cleared-cleared, as in:  All reads return values of 0x00, or 0xFF.... or do you mean "cleared' in that the contents are now scrambled and not what you expected?

The reads come back as 0.

To read or write I do this:

bleprofile_ReadNVRAM(0x60, sizeof(nv_state_t), (UINT8 *)&nv_state);

bleprofile_WriteNVRAM(0x60, sizeof(nv_state_t), (UINT8 *)&nv_state);


I check one of the fields of the struct and if it is 0, I assume that we are booting for the first time; otherwise I do not.  I find that these values survive reset and HIDoff but after removing power completely the field is 0 again.

Is it possible your application is writing to addresses beyond the end of the device and "wrapping around" to the addresses in the beginning?

I don't know, is 0x60 OK?  I don't think that's the problem however since it survives HIDoff.

Are you using OTA upgrade feature?

We do use this feature, and have gotten that working, but that's not involved in this specific instance.

Just some ideas, and of course-all the usual questions apply:   When did this problem start, does it happen on all boards, how can we reproduce it, yada-yada....  🙂


I only tested this just recently and noticed the issue.  I assume that it is a misunderstanding of Read/WriteNVRAM on my part?


If NVRAM indeed does not persist, is there any user-accessible memory that does?



0 Likes

Well, now I reprogrammed that device and it behaves correctly (NVRAM persists after removing power).

I have no idea what was wrong, but it now works the way I expected it to.

Sorry for the confusion.

0 Likes

No problem.  Let us know if you run into any other problems.

0 Likes

We've seen a few more devices that have this problem, but might recover after re-flashing.

Just so I have the right mental model, under what conditions would a call to NVRAM_write() store data that did not persist after power was removed?

In our experience, it always persists across reboots, but it appears that in some cases does not persist across removing the battery.  Is there some internal cache at work here that does not always immediately get written to eeprom, but still remains powered during reset?

0 Likes

Is this problem related to how the RXd (HCI) is used  internally to determine whether or not the part comes up in programming or application mode?

For example, on the TAG board, there is an external pull-up (VDDIO) on Pin 18, which is the HCI UART RXd  line (Note that on the module this pin is pulled low through an internal 10k ohm resistor) and this pullup should cause the part to come up in programming mode. This has confused many because they believe the application was lost during the power recycle, even though the application is still loaded into EEPROM (assuming it had been programmed prior).

 

Then on the TAG board specifically, changing the settings on SW4 essentially places the part back into application mode (take a look at the Viewing Trace section in the QSG, the part is in Application Mode for this procedure) and makes it appear that the programmed application reappears.

 

Ultimately, in a real application you would want the host to drive its TXd (2073x’s RXd) high (not just a pull-up).

0 Likes

Is this problem related to how the RXd (HCI) is used  internally to determine whether or not the part comes up in programming or application mode?

No.  I think my description was not clear.  I am not talking about the storage of the application program itself.

I am talking about the use of the functions

  bleprofile_ReadNVRAM and bleprofile_WriteNVRAM

which I use to store data that my application needs to have persist across reset and power removal.

When my application starts I read data from one of these NVRAM locations and use that to restore my state.

The first time my application runs after being loaded into flash, these locations all contain zeros.

From that I know that this is the first boot and I can initialize my state, etc.  Before going into deep sleep or rebooting, I save my state back to NVRAM so that I can restore it when I run next.

What we are seeing is that under some conditions, a write to NVRAM does not seem to persist after power is removed; for example I might initialize and write out to NVRAM, but then remove power and restore power, and it would enter the initialization code again.

My model for how these functions work is that they immediately write the data to EEPROM, but this can't be the correct model because I have seen cases where the data is not persistent.  This led me to speculate that there might be some kind of caching going on. 

So my question is, based on your knowledge of how it actually works, is it possible for data written to NVRAM to be lost when the battery is removed and replaced?  If so, under what conditions?

0 Likes

Since we are using ThreadX under the hood, is it possible your EEPROM write request did not get time to execute before the power went down?   Does you code perform a write, ... delay ..., and then a read-back to ensure it got written successfully before power down is permitted?   Just a thought.

0 Likes

Power was not removed until a long time after the write was performed (at least several seconds later).

I doubt that the delay would be a hardware limitation (i.e. speed of writing to eeprom) but it could be a design choice (i.e. cacheing the write and writing later to reduce write load).  I am trying to find out whether there is any such behavior as that.

If the system goes into deep sleep or resets, we can still successfully read the data back off NVRAM after we wake up.  But even after sleeping and waking successfully, removing power seems to wipe it. 

Note also that this does not happen on most of my devices.  I've only seen a few devices exhibit this behavior, and they do so persistently, until re-flashing the device cleared up the problem.  In this respect, this seems similar to the problem we have seen where sometimes, after programming our device it cannot receive GATT 'write" commands.  But then after reprogramming it with the same .HEX file, it works.

0 Likes
MichaelF_56
Moderator
Moderator
Moderator
250 sign-ins 25 comments on blog 10 comments on blog

The contents of the EEPROM should not be erased when power is removed.

In addition to your application, the EEPROM includes BD ADDR (Bluetooth Device Address), Patches and Bonding/Pairing information.

Regarding the application, the SDK downloads a minidriver to RAM then pushes the code over the HCI uart to the minidriver which will then write to EEPROM.

0 Likes