What are the differences between the various SDK builds?

[TD-er]

See the list of SDK2xx defines:

Arduino/tools/platformio-build.py

Lines 167 to 197 in 3db610f

	elif "PIO_FRAMEWORK_ARDUINO_ESPRESSIF_SDK221" in flatten_cppdefines:
	#(previous default)
	env.Append(
	CPPDEFINES=[("NONOSDK221", 1)],
	LIBPATH=[join(FRAMEWORK_DIR, "tools", "sdk", "lib", "NONOSDK221")]
	)
	elif "PIO_FRAMEWORK_ARDUINO_ESPRESSIF_SDK22x_190313" in flatten_cppdefines:
	env.Append(
	CPPDEFINES=[("NONOSDK22x_190313", 1)],
	LIBPATH=[join(FRAMEWORK_DIR, "tools", "sdk", "lib", "NONOSDK22x_190313")]
	)
	elif "PIO_FRAMEWORK_ARDUINO_ESPRESSIF_SDK22x_191024" in flatten_cppdefines:
	env.Append(
	CPPDEFINES=[("NONOSDK22x_191024", 1)],
	LIBPATH=[join(FRAMEWORK_DIR, "tools", "sdk", "lib", "NONOSDK22x_191024")]
	)
	elif "PIO_FRAMEWORK_ARDUINO_ESPRESSIF_SDK22x_191105" in flatten_cppdefines:
	env.Append(
	CPPDEFINES=[("NONOSDK22x_191105", 1)],
	LIBPATH=[join(FRAMEWORK_DIR, "tools", "sdk", "lib", "NONOSDK22x_191105")]
	)
	elif "PIO_FRAMEWORK_ARDUINO_ESPRESSIF_SDK22x_191122" in flatten_cppdefines:
	env.Append(
	CPPDEFINES=[("NONOSDK22x_191122", 1)],
	LIBPATH=[join(FRAMEWORK_DIR, "tools", "sdk", "lib", "NONOSDK22x_191122")]
	)
	else: #(default) if "PIO_FRAMEWORK_ARDUINO_ESPRESSIF_SDK22x_190703" in flatten_cppdefines:
	env.Append(
	CPPDEFINES=[("NONOSDK22x_190703", 1)],
	LIBPATH=[join(FRAMEWORK_DIR, "tools", "sdk", "lib", "NONOSDK22x_190703")]
	)

I have been switching between those versions like PIO_FRAMEWORK_ARDUINO_ESPRESSIF_SDK22x_191122 and PIO_FRAMEWORK_ARDUINO_ESPRESSIF_SDK22x_190703.

On most units the 'November' build works just fine, while on some units the 'July' build was the only one that could reliably make a stable WiFi connection.

Purely based on what I'm observing, it seems some default values may have changed.
For example:

• Timeout for WiFi scanning
• initial connection speed
• Delays between actions.

But there are way too many variables possible to even start digging into what may have been changed between these SDK builds.
So maybe someone can shed some light on what actually has been changed with respect to WiFi configuration and when to use what SDK build.
Or how to interpret these differences so we can set them on our own.

[Jason2866]

Probably only espressif knows. Nearly no infos https://github.com/espressif/ESP8266_NONOS_SDK/commits/release/v2.2.x

[atharvamulgund]

Respected Developer's, I am student pursuing my engineering. I am working on ESP 8266/Arduino and I need to how to link a webpage to the ESP8255/Arduino created hotspot IP address

…

On Thu, 2 Jul, 2020, 3:56 PM TD-er, ***@***.***> wrote: See the list of SDK2xx defines: https://github.com/esp8266/Arduino/blob/3db610f6d0755ff114302df586bbf1e6404a518e/tools/platformio-build.py#L167-L197 I have been switching between those versions like PIO_FRAMEWORK_ARDUINO_ESPRESSIF_SDK22x_191122 and PIO_FRAMEWORK_ARDUINO_ESPRESSIF_SDK22x_190703. On most units the 'November' build works just fine, while on some units the 'July' build was the only one that could reliably make a stable WiFi connection. Purely based on what I'm observing, it seems some default values may have changed. For example: - Timeout for WiFi scanning - initial connection speed - Delays between actions. But there are way too many variables possible to even start digging into what may have been changed between these SDK builds. So maybe someone can shed some light on what actually has been changed with respect to WiFi configuration and when to use what SDK build. Or how to interpret these differences so we can set them on our own. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#7421>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/APIAKI4IEODJ3S7GXEKAJWDRZROF5ANCNFSM4OOX3GRA> .

[earlephilhower]

@TD-er, this would be nice to have but the Arduino Core's not going to be able to help here. The Espressif changelogs are somewhat sparse for the blobs. That's why we put in a few versions because each one has its own quirks. I believe you helped debug the 3.x and found it would freeze in the blob for 100s of ms, for example.

[devyte]

@TD-er Previous comments are correct. The only info available to anyone is the commit history in the nonos repo linked above, which you can access yourself, and which has very little info.
Closing.

[JAndrassy]

I think this is behind some strange things when changing SDK version on a unit:

for proper system operation, it is highly recommended that the esp_init_data.bin and blank.bin files be flashed to the correct location in memory at least once. For ESP8266_NONOS_SDK_v2.2.1 and later versions, the RF calibration sector must be set correctly in the application user_rf_cal_sector_set.

https://www.espressif.com/sites/default/files/documentation/2c-esp8266_non_os_sdk_api_reference_en.pdf

core flashes esp_init_data as part of the sketch binary, but for RF calibration sector blank.bin is recommended, not only flash erase.

[devyte]

Neither of Espressif's recommendations apply to us, because we don't flash those areas separately like their apps do. If you flash blank.bin manually, it is highly likely that you won't get it right (our wifi config area is not in the same place).
In our case, when flashing over serial, you need to erase all flash when changing sketch type. In truth it's more complicated than that, but as a general rule of thumb that should serve. When doing OTA, things get complicated in an entirely additional dimension, but @mhightower83 implemented a PoC in #6965.

[JAndrassy]

Neither of Espressif's recommendations apply to us, because we don't flash those areas separately like their apps do. If you flash blank.bin manually, it is highly likely that you won't get it right (our wifi config area is not in the same place).
In our case, when flashing over serial, you need to erase all flash when changing sketch type. In truth it's more complicated than that, but as a general rule of thumb that should serve. When doing OTA, things get complicated in an entirely additional dimension, but @mhightower83 implemented a PoC in #6965.

sorry, I always thought blank.bin are zeros. And it is full of FF like an ereased flash

[Jason2866]

Project Tasmota has implemented a command to erase the rf calibration sector to initiate a recalibration. It does help for some devices which behaves bad when SDK version is changed.
BUT we have found out that only version NONOSDK22x_190703 works without issues.
The only version without wifi or mqtt reconnect

[TD-er]

BUT we have found out that only version NONOSDK22x_190703 works without issues.
The only version without wifi or mqtt reconnect

Do you also see issues with some boards where they have issues connecting, or at least that the reported WiFi.status() is incorrect? (see: #7432 )
I use the same SDK as you do apparently for the regular builds, as it somewhat still 'feels' the most stable one.
But as we all appear to agree on here, we simply don't know why.

I will make an issue at Espressif's GitHub with the same topic as we had here.

[Jason2866]

Yes in combination with some routers. The most problematic is Asus. (See arendst/Tasmota#7770 )

[TD-er]

Well I have here several nodes, all connecting to the same AP (Mikrotik) and most work perfectly fine, but I now have one that does fail quite often to connect to it.
After reset of WiFi and trying again, it often connects without issues.
So that's where I'm working on a work-around as the problem seems to be in the SDK
It seems to be a timing issue and it may be possible the Asus ones are just hitting the 'sweet spot' to reproduce this error? Either in being much faster or slower, whatever triggers this issue.