bleprofile_WriteNVRAM Problem

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

cross mob
AnSo_2111241
Level 1
Level 1
Welcome!

Hi guys,

I'm working with a bcm20737 module and lately I'm facing the next problem:

I found that sometimes the bleprofile_WriteNVRAM failed writing in some vsID. I found a solution, reading the same vsID after the write operation and if it the result was not right calling the write operation again. The thing with this bug is that the write operation returned that everything went perfectly, and that it wrotes the correct number of bytes in the NVRAM.

I think that this solution works perfectly, but my problem comes next because I have some devices programmed without the solution and now I have to upgrade them through OTA and when I do this the vsIDs that I could not write correctly are impossible to write even with the new solution (But in this case the write operation allways returns a 0, not like before that returned the correct number of bytes). When I reprogram the module through Wiced everything works as expected but when I upgrade through OTA that vsIDs are like corrupted and are inaccessible neither I can delete them or rewrite them. Anyone faced this same problem?

Many thanks for any help you can provide.

Angel

0 Likes
1 Solution

You can't change the nvram size of 32Kbytes because it has been embedded into the 737S module. If you are refering to the effect of doubling of the VS section, no effect theoretically. Things like your data from the application and pairing information will be stored in VS. I suspect you may have ran out of space...

View solution in original post

10 Replies
BoonT_56
Employee
Employee
500 likes received 250 likes received 100 likes received

I believe you are refering to bleprofile_WriteNVRAM(). I noted that the valid ID numbers are from 0x10 to 0x6f. Could this be the reason for your encounter? Do refer to bleprofile.h for a more detailed explanation.

0 Likes

Yes, I was talking about bleprofile_WriteNVRAM(). Sorry for the mistake, Im going to change the title and the text of my question.

In the case of the IDs, I'm using from 0x31 to 0x4D, so I dont think that is the problem.

0 Likes

0x31 to 0x4d contains 29 IDs. I assume you are using the default length 1024 bytes for your volatile section (VS). FW itself will require 4 pages and you are left with 28 pages. If this is the case then you will encounter write errors. And the maximum size of each record item (data only) is 255 bytes.

0 Likes

Oh, sorry, I misscalculated that. I'm using from 0x31 to 0x4B. And the maximum size of each record item in my program is 29 bytes. And yes Im using the default length.

Another thing that maybe is important is that I reuse (delete the data and then write new data) on some of this iDs. Particullarly the ones that are getting the problem.

0 Likes

I assumed that you have gotten all the various eeprom offsets and configurations correct, it is not obvious what could be the issue. It could be HW, as I note that this bug does not happen all the time. OTA does not update the VS and so the issue was already rooted when you first write into the eeprom. The data was not written correctly and that section was corrupted. Recovery will be able to work around this though. I have the following ideas for your consideration:

1) Implement the write-read-compare check sw loop

2) Consider lowering your eeprom access speed from the default 400KHz to 100KHz

3) Increase the VS size, double it for a start. Do remember to "push out" your DS locations too

May I know what is your failure rate now?

To lower the eeprom access speed which parameter do I have to change? Is in the 20737_EEPROM.btp?

And for the other step I onlyhave to do the next right?

ConfigDSLocation = 2432

DLConfigVSLength = 2048

May I ask which consecuences could have this change into the module?

Than you very much for your atention and your help!

0 Likes

To lower the speed, you can create a file called "eeprom_speed_100.cgs" and save it in your application folder. The content of this file

is as below:

ENTRY "I2C Speed"

{

    "Speed" = "100 KHz"

}

Then, in your make file, insert the following line at the end:

CGS_LIST += $(DIR)/eeprom_speed_100.cgs

As you are reducing the access speed, then the boot-up will take a longer time and probably will affect the power consumption.

BTW, I hope you did the crystal warmup remedy since you are using a module.

On the second option, I don't have the numbers up my head. But the idea is simply not to overlap the VS region and the DS region. Do take note that you must still maintain sufficient size for DS1 and DS2. The latter is for OTA.

Hello again,

After trying the things that you putted before here i have my results:

1) This works well when the write  response is correct but when I read and compare the results are different. When the response of the writing command is 0 it doesnt' work well.

2) Changing this caused the OTA to stop working. I don't know why, but it seemed like in the crc something goes wrong, cause the transfer of the new firmware finishes ok but after that the OTA is cancelled. Could it be that finally I changed the speed in the BCM20737A1.cgs?

3) After some tests this seems to work, I charge the new program and then I make the OTA to the device and all the data seems to still get saved. I'll do some more tests to verify it.

The problem is that the modules with the old FW version don't get fixed when I do the OTA. Is not a big problem but it will be better if I can fix it. Also, I want to ask, what implies changing the size of the NVRAM to the double and reducing the DS?

Thank you very much for your help!

0 Likes

You can't change the nvram size of 32Kbytes because it has been embedded into the 737S module. If you are refering to the effect of doubling of the VS section, no effect theoretically. Things like your data from the application and pairing information will be stored in VS. I suspect you may have ran out of space...

Yes I was refering to the VS xD.

I hope it is that problem and with that is finally solved.

Thank you very much @btta!!

0 Likes