Newbie With Flash Section Questions

[pauliec]

Hello, please redirect me if this is not the correct fourm.

Using ESP32-32D BLE controller chip.

We have 3 code sections we wrote;
0x1000 - bootloader - 26K
0x10000 - application code - 960K
0x8000 - partitions.bin - 4k

We are seeing an issue where ESP32-32D is disconnecting, or the DUT is disconnecting. Because of the factory environment (in a rf shielded enclosure) we have not been able to ascertain, who is at fault here. After 100K iterations of the factory test, I am not able to reproduce the disconnect even once. I have obtained the full flash image of one of the offending dongles. I see the code sections I mentioned above are all in tact and match up to the released code. However I have non-FF data in the 0x9000 to 0xC000 area and also above 00110000.

So, sorry I dont know this, but how do I have non-FF data at those locations if I erased and programmed just the aforementioned code sections? Secondly, what API would I search for in our code to determine what function is writing to these locations?

Any other suggestions are requested

Best Regards

[Sprite]

You'd want to take a look at the partitions.csv you're using. There are a few partitions that are declared, but not flashed by an external programmer; e.g. NVS is used by the ESP itself to store some data in.

[MicroController]

However I have non-FF data in the 0x9000 to 0xC000 area and also above 00110000.

So, sorry I dont know this, but how do I have non-FF data at those locations if I erased and programmed just the aforementioned code sections? Secondly, what API would I search for in our code to determine what function is writing to these locations?

See also https://docs.espressif.com/projects/esp ... ion-tables

The nvs and the phy_init partitions may be written to by the running application when NVS or WiFi is used, respectively. This may be what you're looking at.

[pauliec]

OK, thanks for the pointers.

Based on analysis of our configuration I believe this is the NVS area.

Taking this into the next level of the onion, what is written normally to NVS? Also what is the basic API for reading or writing NVS? Are there any tools for the parsing of this data from a binary I've retrieved?

thanks again for all the help

Paul


P.S

I did try to use the nvs_tool.py and got the following error. The binary is a binary of the entire chip... including the nvs


python nvs_tool.py c82e1816a8f4_0x0_0x400000_20250812_140751.bin
Traceback (most recent call last):
File "C:\temp\esp-idf\components\nvs_flash\nvs_partition_tool\nvs_tool.py", line 124, in <module>
main()
File "C:\temp\esp-idf\components\nvs_flash\nvs_partition_tool\nvs_tool.py", line 82, in main
nvs = nvs_parser.NVS_Partition(args.file.split('/')[-1], bytearray(partition))
File "C:\temp\esp-idf\components\nvs_flash\nvs_partition_tool\nvs_parser.py", line 72, in __init__
self.pages.append(NVS_Page(raw_data[i: i + nvs_const.page_size], i))
File "C:\temp\esp-idf\components\nvs_flash\nvs_partition_tool\nvs_parser.py", line 153, in __init__
entry.compute_crc()
File "C:\temp\esp-idf\components\nvs_flash\nvs_partition_tool\nvs_parser.py", line 278, in compute_crc
if self.data['size']:
KeyError: 'size'

[MicroController]

Also what is the basic API for reading or writing NVS?

https://docs.espressif.com/projects/esp ... flash.html

We are seeing an issue where ESP32-32D is disconnecting, or the DUT is disconnecting.

"Disconnecting"? What kind of connection/protocol is "disconnected"?

[pauliec]

The BLE transport is being disconnected but I am more interested in the dongles operation

We have 3 espressif-32D based chips which are operating completely differently from all the other. All of the dongles have the same application, boot and partition firmware. These 3 dongles seem to disconnection from the target right after connecting. I am looking for clues as why this is occurring.

Since the non code sections are different, I thought I would look in that direction


//paul

[MicroController]

Maybe some kind of pairing/bonding issue?
If two Bluetooth devices, identified by their MAC addresses, were bonded at some point, and (only!) one of the devices has "forgotten" the bonding, connecting again becomes more complicated.