Build and deployment issues with olimex-iot-firmware-esp8266

Started by meinereiner, December 19, 2016, 10:39:26 AM

Previous topic - Next topic

meinereiner

Hi,

I'm experimenting with the "olimex-iot-firmware-esp8266" and as a start I just want to build and deploy a version.

When I just deploy a prebuild version, everything is working like a charm:
esptool/esptool.py --baud 576000 write_flash 0x00000 bin/boot_v1.5.bin 0x01000 bin/upgrade/EVB_ONLY/user1.2048.new.3.bin 0x81000 bin/upgrade/EVB_ONLY/user2.2048.new.3.bin 0x100000 bin/blank.bin 0x1FC000 bin/esp_init_data_default.bin 0x1FE000 bin/blank.bin --flash_size 16m
The board boots up and I can connect to it an use the REST interface.

When I'm taking the source code as it is from GitHub and just build it:
make clean && make APP=1 && make APP=2
(I do not build it for a specific device, I habe also tested it to build up for EVB_ONLY)
Then uploading it:
esptool/esptool.py --baud 576000 write_flash 0x00000 bin/boot_v1.5.bin 0x01000 bin/upgrade/user1.2048.new.3.bin 0x81000 bin/upgrade/user2.2048.new.3.bin 0x100000 bin/blank.bin 0x1FC000 bin/esp_init_data_default.bin 0x1FE000 bin/blank.bin --flash_size 16m
From the serial console it doesn't look strange so far. I only do not see the Wifi. When I reboot the device endy up in an endless loop.

I have also tried to upload user2 via the HTTP. Same.
I also tried just to upload the two newly build files. Same.

What am I doing wrong?

JohnS

Is the one that fails bigger (for example)?

Otherwise you could use diff etc to find what's changed.

John

PeteW

Can you compare your binaries with those from https://github.com/OLIMEX/olimex-iot-firmware-esp8266/tree/master/bin/upgrade/EVB_ONLY

Are they the same or different?

How you setup your toolchain?

I'm currently using https://github.com/pietrushnic/esp-open-sdk

meinereiner

Thanks for your answers!

I'm currently using a docker image to build the files:
https://github.com/vowstar/esp8266
https://hub.docker.com/r/vowstar/esp8266/
I had some issues on local installation on conflicting libraries on my machine so I've chossen the docker image.

I have configured the SDK_BASE manually to ensure that I'm using the sources of 2.0.

Why so ever, the reulting bin files do differ (compared to https://github.com/OLIMEX/olimex-iot-firmware-esp8266/tree/master/bin/upgrade/EVB_ONLY) when I build it by my own.

Any idea why?

PeteW

I had similar issues when moving my environment to a different computer. I tried using toolchain from https://github.com/pfalcon/esp-open-sdk and result was the same you describe.

Using https://github.com/pietrushnic/esp-open-sdk solved my problem.

meinereiner

@PeterW: Thanks for your hint. I will give it a try.
Stupid question: Did you just clone it and set the PATH variables correctly or did you do other things as well?

PeteW

As I remember

1. I cloned it
2. build it make STANDALONE=y (it took about 25-30 minutes)
3. manually set the path.

meinereiner

Ok I have checked it out and compited it again and uploaded via website just user2. Same.

By the way: old way as well as new way tells me when I upload in the last line on the console a wdt reset:


ets Jan  8 2013,rst cause:1, boot mode:(1,7)


ets Jan  8 2013,rst cause:4, boot mode:(1,7)

wdt reset


PeteW

Can you try

esptool/esptool.py \
--port /dev/ttyUSB0 \
--baud 576000 \
write_flash \
0x00000  bin/boot_v1.6.bin \
0x01000  bin/upgrade/user1.2048.new.3.bin \
0x81000  bin/upgrade/user2.2048.new.3.bin \
0x100000 bin/blank.bin \
0x101000 bin/blank.bin \
0x102000 bin/blank.bin \
0x103000 bin/blank.bin \
0x1FC000 bin/esp_init_data_default.bin \
0x1FE000 bin/blank.bin \
--flash_size 16m


There are some changes in esp_init_data_default.bin for version 2.0.0 of the SDK

meinereiner

#9
Unfortuantely the same...

The new flash script doesn't accept "--flash_size 16m" anymore.

Just to sum it up again what I did:
- I have downloaded and build the toolchain with the link mentioned above (esp-open-sdk). I added that path where the toolchain is to the PATH
- I have checked out the Olimex project from github
- I placed the SDK 2.0 in the tools folder
- I have build APP=1
make SDK_BASE=".../tools/ESP8266_SDK" FLAVOR="release" APP=1
- I have build APP=2
make SDK_BASE=".../tools/ESP8266_SDK" FLAVOR="release" APP=2
- I have uploaded:
.../esp-open-sdk/esptool/esptool.py --port /dev/ttyUSB0 --baud 576000 write_flash 0x00000  bin/boot_v1.6.bin 0x01000  bin/upgrade/user1.2048.new.3.bin 0x81000  bin/upgrade/user2.2048.new.3.bin 0x100000 bin/blank.bin 0x101000 bin/blank.bin 0x102000 bin/blank.bin 0x103000 bin/blank.bin 0x1FC000 bin/esp_init_data_default.bin 0x1FE000 bin/blank.bin

Then the reset happens!
[Remark: I have just shorted my path with ... in the example above]



EDIT:
By the way: When I build the entire files:

Generate eagle.flash.bin and eagle.irom0text.bin successully in folder bin.
eagle.flash.bin-------->0x00000
eagle.irom0text.bin---->0x40000

and flash them:

...esptool/esptool.py --port /dev/ttyUSB0 --baud 576000 write_flash 0x00000  bin/eagle.flash.bin 0x40000  bin/eagle.irom0text.bin
]
Then the device is in an endless loop as well, but a different one. I only see tons of bytes beeing send out via UART.

PeteW

olimex-iot-firmware-esp8266 includes SDK 2.0.0 there is no need overwrite the SDK. There are minor changes in our makefiles.

Can you try it without replacing the SDK.

make clean
make DEVICE=EVB_ONLY APP=1
make clean
make DEVICE=EVB_ONLY APP=2

meinereiner

It is still sontstantly resetting when I flash:
.../esp-open-sdk/esptool/esptool.py --port /dev/ttyUSB0 --baud 576000 write_flash 0x00000  bin/boot_v1.6.bin 0x01000  bin/upgrade/EVB_ONLY/user1.2048.new.3.bin 0x81000  bin/upgrade/EVB_ONLY/user2.2048.new.3.bin 0x100000 bin/blank.bin 0x101000 bin/blank.bin 0x102000 bin/blank.bin 0x103000 bin/blank.bin 0x1FC000 bin/esp_init_data_default.bin 0x1FE000 bin/blank.bin
The bins user1 and user2 are build with
make DEVICE=EVB_ONLY APP=...

PeteW


meinereiner

[I only replaced by path with ...]

xtensa-lx106-elf-gcc -v
Using built-in specs.
COLLECT_GCC=xtensa-lx106-elf-gcc
COLLECT_LTO_WRAPPER=.../esp-open-sdk/xtensa-lx106-elf/libexec/gcc/xtensa-lx106-elf/4.8.2/lto-wrapper
Target: xtensa-lx106-elf
Configured with: .../esp-open-sdk/crosstool-NG/.build/src/gcc-4.8.2/configure --build=x86_64-build_unknown-linux-gnu --host=x86_64-build_unknown-linux-gnu --target=xtensa-lx106-elf --prefix=.../esp-open-sdk/xtensa-lx106-elf --with-local-prefix=.../esp-open-sdk/xtensa-lx106-elf/xtensa-lx106-elf/sysroot --disable-libmudflap --with-sysroot=.../esp-open-sdk/xtensa-lx106-elf/xtensa-lx106-elf/sysroot --with-newlib --enable-threads=no --disable-shared --with-pkgversion='crosstool-NG 1.20.0' --disable-__cxa_atexit --with-gmp=.../esp-open-sdk/crosstool-NG/.build/xtensa-lx106-elf/buildtools --with-mpfr=.../esp-open-sdk/crosstool-NG/.build/xtensa-lx106-elf/buildtools --with-mpc=.../esp-open-sdk/crosstool-NG/.build/xtensa-lx106-elf/buildtools --with-isl=.../esp-open-sdk/crosstool-NG/.build/xtensa-lx106-elf/buildtools --with-cloog=.../esp-open-sdk/crosstool-NG/.build/xtensa-lx106-elf/buildtools --with-libelf=.../esp-open-sdk/crosstool-NG/.build/xtensa-lx106-elf/buildtools --enable-lto --enable-target-optspace --disable-libgomp --disable-libmudflap --disable-nls --disable-multilib --enable-languages=c,c++
Thread model: single
gcc version 4.8.2 (crosstool-NG 1.20.0)

PeteW

It looks OK. I'm out of ideas for now. I'll try to reproduce the problem with clean install. This can take some time.