Close

Changing firmware of ESP8266 and other stuff

A project log for Cypress PSOC 4 + ESP8266 WS2812 RGB XMAS Lights

802.11 WIFI enabled RGB LED Strips, using the ESP8266 and $4 Psoc 4 dev board.

charliexcharliex 12/25/2014 at 01:540 Comments

I finally got around to compiling up the ESP8266 firmware on windows, i'd previously setup an EC2 instance beforehand and got it compiling but not tested it.

I used CHERTS setup here , which actually seemed to work as documented! amazing stuff :)

http://www.esp8266.com/viewtopic.php?f=9&t=820

Once i'd fiddled around with python adding all the extra stuff it needs, and gave up on the cygwin version of esptool.

Compiled new firmware and was left with the at_v0.20 9,3 sdk and firmware files

C:\Espressif\examples\at_v0.20_on_SDKv0.9.3\firmware

12/24/2014 17:18 35,120 0x00000.bin
12/24/2014 17:18 160,992 0x40000.bin

ok grab https://github.com/themadinventor/esptool setup python with serial support etc.

quick batch file name it flash.bat and use flash COM4 (or whatever yours is)

c:\esptool-master\esptool.py --port %1 write_flash 0x00000 0x00000.bin
pause reset the esp
c:\esptool-master\esptool.py --port %1 write_flash 0x40000 0x40000.bin

These last two are only needed if you want to reset the settings.

pause reset the esp
c:\esptool-master\esptool.py --port %1 write_flash 0x7C000 C:\Espressif\ESP8266_SDK\bin\esp_init_data_default.bin
pause reset the esp
c:\esptool-master\esptool.py --port %1 write_flash 0x7E000 C:\Espressif\ESP8266_SDK\bin\blank.bin

Connect to a 3.3V UART, ground GPIO 0 , reset the ESP , flash each section, resetting in between.

in user_main.c i changed the UART setup too :-

uart_init(BIT_RATE_921600, BIT_RATE_115200);

then flashed up the image and got it running at 921600 baud, a few false starts but the reset settings above, will help you. It also loses the CIOBAUD command, which is easy to add back.

so then i ran my CIPSERVER with a UDP port as usual, and nada. . so reflashed back and forth, the usual head scratching and eventually figured look at the code in the firmware, sure enough in at-ipCmd.c UDP listener is commented out. look for and start un-commenting here

  // pUdpServer = (struct espconn *)os_zalloc(sizeof(struct espconn));
then that whole section is commented out (not sure why lines of // vs #if 0), up until, stop un-commenting on the line before this.
//    pLink[0].pCon->type = ESPCONN_TCP;
now look for this, which is also commented out ( i don't know if eclipse has a vertical select like VS does, and frankly i don't want too )
at_udpserver_recv(void *arg, char *pusrdata, unsigned short len)
Keep an eye on this routine, since this is why i'm doing the firmware updates anyway.

Recompile and re-flash, and you ought to be back in business with UDP.

also in at_cmd.c i modified line 150 to stop compiler noise

    else if(((*pAtRcvData >= '0') && (*pAtRcvData <= '9') )|| (*pAtRcvData == '='))

Finally in PSoC creator, change the baud rate for the XMAS lights on the WIFI UART thusly

Re-flash the PSoC light node and test !

So at first sight the LED's do seem smoother at this baudrate, but that's entirely subjective and the limiting factor maybe elsewhere, its also been a long week ;) but lets call it a win win all around

update: I put one of the new code nodes up along with the old ones, and its significantly faster..

The reason i want to redo the code in the firmware is to get rid of the +IPD,0,length:, and any trailing data, from the CIPSERVER, since i'm looking at something that requires the data to have nothing extra added. While its useful in a lot of places, i can do without it here.

Also i'd like to note back on that long week thing, sometimes you look for something, say the protocol for a bootloader and you expect the OEM not to give it to you, so you poke around and find DLL's that look interesting, then spend a couple of hours completely reverse engineering them back to working C code , then look for API call documentation to give it that extra va-voom and you then discover that in fact they did give you the code for a different version of the bootloader that has got enough info.. The moral of the story is that i'm a pretty awesome RE'r and got the RE'd code back to pretty much the supplied code, and that sometimes maybe you should look for the API doc's a bit harder next time, but also seeing the code side by side looking the same is good booster. Hopefully more on this later.

Discussions