Migrating applications from SDK 1.3 to SDK 1.4

[kolban]

We have an application that we are testing which works fine under SDK 1.3. We decided to test it using SDK 1.4. Our method was to download the SDK and rebuild the source from a clean state pointing to the SDK 1.4 include files and the SDK 1.4 libraries. The compilation was still 100% clean. However, what we seem to be finding is that when we run our app and we reach the wifi_station_connect() api (Our app connects to an AP) the app will not connect our ESP to the AP. The device remains in "STATION_CONNECTING" mode and there is nothing logged to the debug console. The WiFi event callbacks showing status don't get called. In fact nothing at all seems to happen.

If I switch the same code back to SDK 1.3 and clean build, all now works again.

So either there has been a regression from SDK 1.3 to SDK 1.4 or (which I believe is more likely) there has been some new set of changes that I now need to accommodate in the app to allow WiFi connections to work.

Has anyone found any obvious changes to their apps logic, flow or design that were needed for a 1.4 migration? Does an ESP have to be somehow "prepped" for SDK 1.4?

Neil

[blubb]

Have you tried re-flashing esp_init_data_default.bin?

[masacate]

Hi,
I have also similar problem, I had to go back from sdk 1.4 to 1.3, my program that worked perfectly with the 1.3 version is continually trying to connect because of errors with the 1.4 version

masacate

[tve]

I also have a problem like this. I am switching between two very different firmwares that both use SDK 1.4. In both cases I am using the same esp-12 module (4MB flash) and I flashed a fresh bootloader 1.4, fresh blank.bin, and esp_init_data_default. In order to switch between the two firmwares I simply flash user1.bin to 0x1000 (both are the OTA-style binary).

In the firmware that connects well, a scan looks like this:

Code: Select all

 15131> Wifi connect failed. Going into STA+AP mode..
 15132> mode : sta(18:fe:34:a6:e8:8f) + softAP(1a:fe:34:a6:e8:8f)
 15137> add if0
...
166158> scandone
166158> bss1: tve-home (-66)
166159> bss2: oc1 (-48)

In the firmware that doesn't connect, a scan looks like this:

Code: Select all

mode : sta(18:fe:34:a6:e8:8f)
add if0
scandone
ssid: oc1


What could be different? I see that on one case the SDK prints "bss1:" in the other "ssid:"

[tve]

I found one issue: prior the SDK 1.4 the scan results had a bogus 0-th entry, this got fixed in SDK 1.4. Maybe I overlooked that in the release notes? But I am still puzzled why the SDK prints "bss" in one case and "ssid" in the other...

[eriksl]

Really, always? That means I will have to "fix" my code, it now always ignore the first entry. I can't remember having seen a note on this.

[Triacon]

Here's more regarding skipping the first entry (Nothing about them(espressif) removing it though):
viewtopic.php?f=66&t=697

Regarding bssid) vs ssid that's probably because what it listed is actually ssids and not bss(id).
BSSID is the (unique)MAC of the AP found, multiple APs can have the same SSID

[eriksl]

Yes I was aware of that, but not the fixing of the problem.

[masacate]

My problems with my router and the SDK 1.4 that forced me to use the !.3 version again has been solved withe the SDK update esp_iot_sdk_v1.4.1_pre5_15_10_27
thanks