Page 1 of 1
Proper way to init phy_init and NVS?
Posted: Thu Dec 08, 2016 10:02 pm
by rojer9
ESP8266 used to ship a small init file for sys params area.
i see that esp-idf does not flash anything to these areas, but i'd like to initialize them to known state.
is it ok to just erase the area (i.e. fill with 0xff)?
Re: Proper way to init phy_init and NVS?
Posted: Fri Dec 09, 2016 1:37 am
by ESP_Sprite
Yes, that should work.
Re: Proper way to init phy_init and NVS?
Posted: Fri Dec 09, 2016 2:42 am
by ESP_igrr
If you have selected an option "Use a partition to store PHY init data", then PHY init binary will be generated as part of the build process and will be flashed with "make flash" or "make phy_init_data-flash". If that option is not selected, PHY init data will be stored in .rodata of the application, so you don't need to erase anything.
Actually this option for using a partition for PHY init data is designed for manufacturers who need to provide different init data based on region, but with single application binary for all regions.
Regarding NVS, it should be able to initialize with any random data present in flash. If you want to make sure it doesn't contain any data, writing an empty 0xff binary to the location of NVS would indeed work.
Re: Proper way to init phy_init and NVS?
Posted: Fri Dec 09, 2016 10:24 am
by rojer9
ah, so there is an option to generate PHY data. i'll use it then.
i want "miot flash" to bring device to a known clean slate, so i think i'll erase NVS just to be sure.
thank you, gentlemen!
Re: Proper way to init phy_init and NVS?
Posted: Fri Dec 09, 2016 11:53 am
by ESP_igrr
Well, PHY init data is always generated... In one case the object file with this data is linked into the application directly. In another case it is dumped as binary, and flashed to some location. I think most applications can use the default (don't place phy init data into partition, link it into application), which is just harder to get wrong.
Re: Proper way to init phy_init and NVS?
Posted: Mon Jan 16, 2017 9:29 am
by zizoalbert
Hello,
I have a question about phy_init partition:
How can we get the factory configuration of this phy_init partition ?
Best wishes
Re: Proper way to init phy_init and NVS?
Posted: Mon Jan 16, 2017 10:41 am
by ESP_igrr
Select "Use a partition to store PHY init data" in menuconfig, then run
make phy_init_data
Output file will be in build/phy_init_data.bin.
To flash just this file, run
make phy_init_data-flash
This file is also generated if you just run "make", and is flashed to the ESP32 if you run "make flash".
Re: Proper way to init phy_init and NVS?
Posted: Fri Nov 05, 2021 7:51 pm
by patakil
ESP_igrr wrote: ↑Fri Dec 09, 2016 2:42 am
If you have selected an option "Use a partition to store PHY init data", then PHY init binary will be generated as part of the build process and will be flashed with "make flash" or "make phy_init_data-flash". If that option is not selected, PHY init data will be stored in .rodata of the application, so you don't need to erase anything.
Actually this option for using a partition for PHY init data is designed for manufacturers who need to provide different init data based on region, but with single application binary for all regions.
Regarding NVS, it should be able to initialize with any random data present in flash. If you want to make sure it doesn't contain any data, writing an empty 0xff binary to the location of NVS would indeed work.
Could you please explain more about which case should CONFIG_ESP32_PHY_INIT_DATA_IN_PARTITION be enabled, and how will the esp-idf include region-specific init data? Will it check the host PC for the region?
We are going to release our product in multiple regions (US, EU, APAC) and I am wondering if I need this option to be enabled and take any further actions to meet the region-specific RF standards?
https://www.espressif.com/sites/default ... ide_en.pdf
https://www.esp32.com/viewtopic.php?t=1020
I found here more information. I can see now that if I want to save power I can fine-tune the radio however, I am more interested in the region-specific use case, which you explained above.
Thank you