Espressif released a new version of their NonOs SDK. The new Version is 2.0.0 released on July 19, 2016. The change from 1. something to 2. suggests it might break the code. I downloaded the new version.
Last week I crippled the software for debugging purposes. I found the bug. This week I want to update to the new version of the SDK. Since it might break my code, I want to get all the functionality back in the code before I move to the new SDK.
First, I uncommented the HSPI overlap test code. I made a small change to the code that reads out from the SPI RAM to guarantee there is a null terminator in the 13th position of the buffer that is filled from the SPI RAM. Then I compiled and tested it. It immediately crashed. I am really glad I haven’t upgraded the SDK yet.
I put hspi_overlap_deinit(); directly after the call to the writeRam(); function. It didn’t crash, but I didn’t get the Hello World from the SPI RAM. I need to init and deinit hspi overlap mode in the writeRam() and readRam() functions. I modified these two functions and tried again. Now I get the Hello World after the menu after a reset.
Next, I enabled the WiFi modem. I set the wifi opmode to STATION_MODE and commented out the other lines that disabled the modem. It booted, I set the SSID and Password, requested a connect and no apparent result. I remembered the WiFi Callback is still disabled, I uncommented that and tried again. This time, it remembered the settings from the previous try and connected immediately.
Next, I re-enabled the Sigma Delta circuit and tried changing values. It is working without crashing. The code is where it should have been before the buffer overrun bug. I am ready to upgrade the build environment.
I am going to use this code as my base going forward because the web server code was unstable, and I don’t want to work with the web protocols as much as that would require.
I did some of these tests while the file was downloading from Espressif’s website. I ran make with the clean option. This removes all the intermediary files used in compiling. Next, I copied the folder I was working with to UProgrammer-SDK1.5.4 This gives me something to go back to if the upgrade fails. Next I opened up the zip archive of the new SDK. I copied all the files and folders in the ESP8266_NONOS_SDK into the UProgrammer folder. This copies over all the SDK files but leaves all my files in place. It does mean the linker file I modified will get overwritten as well. I checked this file and they have changed it in the new version of the SDK. It doesn’t match my linker file, but it might have enough room for my code. I decided to try compiling without modifying the linker file.
There are linker errors but they are not based on code size. They describe undefined references to user_rf_cal_sector_set in function flash_data_check. This looks like a makefile error. I compared the makefile in the app directory with the one in my project directory. There was no makefile in the app directory like there has been in previous versions of the SDK. I went into the examples folder and used the makefile from the IOT_Demo Example for my comparison. I did some clean up and made some changes to make the files closer to each other.
The changes I made weren’t enough, So I copied the whole file over to see if it fixed it. It didn’t, It looks like a file library file isn’t being linked in. I went into the lib directory looking for the library I needed to link. user_rf_cal_sector_set sounds like a memory function to me. So I looked for a library that dealt with calibration memory. In the include directory, used the following command line:
grep -r user_rf_cal_sector *
and I got no results back, so for a sanity check, I tried the following command:
grep -r smartconfig *
and I got a list of lines with smartconfig listed.
On a hunch, I decided to remove the link to main. In the makefile under LINKFLAGS, I removed the line -lmain \.
That also didn’t work. I did the following command in the UProgrammer foler:
grep -r user_rf_cal_sector *
The result looks like every example implements this function. So I copied that function into user_main.c from the IOT_Demo user_main.c and it turns out they required this new function because they changed the layout of the flash calibration data. Now it builds. Now the code no longer works.
I tried changing the ld file back to having a length of 0xC0000 and I noticed that the build said I should upload the code to 0x10000. My shell scripts upload the code to 0x40000. So, I restored my makefile from the copy of the folder and tried again. It still builds to load at address 0x10000. I modified my script file to load to that location.
And finally, success. I set the SSID and the password and requested a connect. it seemed to stall. I reset the board and it connected immediately. I am going to have to take a look at that.
I tested the Sigma Delta and that worked as expected. I measured 22 volts on the output with a duty of 102 and Prescaler of 4.
I re-uploaded the default settings and tried again. I set the SSID, Password, and requested a connect. it seemed to stall again. I waited ten minutes to see if something would change. I looked at the connect request code while I was waiting. Somewhere along the development I deleted the actual call to connect. I didn’t make it to the full ten minutes. Put the connect request in the code, compiled it, reset the flash to defaults, and uploaded the new version.
This time it connected in about 5 seconds. Success. I have uploaded the new version of the code to GitHub, click the Firmware on GitHub link at the top of the right column to go get it or just take a look.
Please comment below about your experiences upgrading to a new version of API/APK. Maybe you have had similar experiences switching between devices in a processor family? I would love to hear from you.