Tag Archives: SDK Migration

New Release of Espressif’s SDK (Firmware Version 00I)

by

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.

Update to SDK 1.5.4 Firmware V00J

by

Since I don’t seem to be making any progress on the Sigma Delta output, I decided to update my copy of Espressif’s API. I went to bbs.espressif.com and clicked on the SDKs thread under the heading DOWNLOADS. In the list i looked for the most recent Non OS SDK release.  I saw that ESP8266_NONOS_SDK_V1.5.4_16_05_20 is the most recent release. It’s file name indicates a release date of May 20th 2016.  I downloaded the zip file and extracted the contents.

To Make moving forward a little easier, I renamed the SDK folder to UProgrammer.  This will help me maintain paths the next time I move to a new SDK Version.  Each time I update to a new SDK, I will Rename the OLD SDK folder to indicate it’s version number, and rename the new SDK folder to UProgrammer.  To maintain compatibility with Github’s folder naming, I will continue to keep the UProgrammer-Firmware folder name for the project files.  This folder will be sitting in the SDK folder I just renamed to UProgrammer.  I then created an empty text file with the name of the SDK file to mark the version I am working in.  Then I copied the hidden file .metadata from the old SDK folder into the new (UProgrammer) SDK folder.

I opened eclipse and pointed the workspace to the UProgrammer folder and it loaded the files as if I hadn’t changed anything. Then I made edited the comment block at the top of the file to indicate I had moved to NONOS SDK V1.5.4.  I saved the file and then checked the file in the new directory structure for the changes. It has the change I had just made.  To make sure there wasn’t something weird going on, I also checked the file in the old directory structure. It was unchanged.  I had planned on dealing with more problems just in case they happened.

I compiled the code to see if anything broke moving to the new SDK.  Things definitely broke. First the files all compiled but linking failed.  The first error message was:

section `.irom0.text' will not fit in region `irom0_0_seg'

This reminded me that I modified the linker file eagle.app.v6.ld to allow for more room for the code space in a 4MByte flash chip.  I made the modification to the new file and saved it.

Modified linker file

I tried compiling again.  Again it failed to link but I was no longer getting the memory failure. This time the first error message was:

 undefined reference to `uart0_sendStr'

I didn’t have the most recent programming reference, so I went back to bbs.espressif.com to download it.  I got the 2C-ESP8266_SDK_API Guide_EN_1.5.4.pdf.  It turns out uart0_sendStr() isn’t in the documentation.  So I looked in my code to find it.  I found the prototype for it in uart.h. but it doesn’t appear anywhere else. This makes me wonder how I was compiling last week.  I did find it in uart.c in the drivers folder.  At one time that file was part of the project. I am guessing the object file was still getting linked in to the project.  The compiled object files are in hidden folders and didn’t get copied by default.  (It’s a good thing.  The versions of code on Github would not have worked. Now they will get fixed.)  I copied The code for uart0_sendStr() into simple_serial.c and recompiled expecting it to fail because uart0_sentStr() calls something else in uart.c.

Again I looked at the first error from the linker which was:

../lib/libat.a(at_ipCmd.o): In function `at_set_rx_buf_state':
(.irom0.text+0x10ac): undefined reference to `espconn_secure_sent'

I am not using any secure features or any AT functions, so I decided to look at the make files. I used a Linux tool called meld to compare files.  There were very small differences.  Looking at my makefile, I noticed four lines that effectively added the -lat linker option.  I commented out those 4 lines and recompiled.  Now the linker only has 4 errors remaining, all of which can be fixed by copying code from the uart.c file.  After copying each function I needed from uart.c, I finally got a successful compile of the code.  I then uploaded it to the PCB to see if it still runs.  It ran the wrong code.  I now get a message in the serial terminal “dmode : softAP (XXX) indicating it is booting up as an access point.

I was able to connect to the device and dhcp worked, but an attemp to connect by http was refused.  Since the messages are system messages I decided to try a UART Swap. No change in the behavior.  I need to do a sanity check, this is a new API so back to doing a Hello World test. I finally got confirmation that my code is what is being uploaded to the module.  I placed the following function call:

system_set_os_print(0); // Turn off System Messages

into the code. I am no longer getting any output in the terminal.  I wasn’t getting any error from compiling but it turns out the function uart_tx_one_char() needed to be copied from the uart.c to simple_serial.c I chose not to have uart.c to reduce code size, there is a lot of code in uart.c that I will never use.

I cleaned up some of the things I tested recompiled and posted a new copy to Github. Do you have any tips for migrating between environments? I’d love to hear about them.