ESP8266 Community Forum

- Sat Feb 13, 2016 9:18 pm #41075 (Because TerryE keeps 719'ing me on GH, I'll comply and bring this issue here. )

This issue originally surfaced when I had #DEVELOP_VERSION enabled to do some debugging (#976). I already need a lot of different modules, and with the additional debugging, it pushed the build size of the 0x10000.bin over 0x6c000 (442,368 bytes) in length. Note that this is for an ESP-12, so flash storage space was not a concern.

Notice for the quick readers: This issue has nothing to do with using #DEVELOP_VERSION, but rather everything to do with the resulting size of the 0x10000.bin when you have a lot of modules selected. In my case, having #DEVELOP_VERSION defined just happened to take the size of 0x10000.bin over 442,368 bytes in length, but I have replicated by selecting all of the modules.

When the device boots/resets, different behavior was observed depending on variations in the .bin size (Panic-Reset loops, spitting out 0xFE characters forever, or just repeated resets with no Panic messages, etc). But the consistency was in the fact that large builds refused to work.

(For the record, my toolchain is using 1.5.1 SDK)

My question for those knowledgeable about the memory map/compiling/linking process: is there something magical about that 0X6C000 length in general, so that builds simply will not work if it is larger? Or could there be an issue with the linker scripts, or IRAM size, etc?

I discovered in Espressif's 2A documentation (http://bbs.espressif.com/download/file.php?id=1074) that in SDK 1.5 that the flash map is as follows (for the 4096 KB flash size, which the ESP-12 module has):

Code: Select all00 0000 - 00 FFFF = Flash.bin     (max 64 KB)
01 0000 - 03 BFFF = User Data     (176 KB + any leftover in flash.bin's 64 KB space)
03 C000 - 03 FFFF = User Param    (16 KB)
04 0000 - 0F FFFF = Irom0text.bin (max 768 KB)
0C 0000 - 3F BFFF = User Data     (3056 KB + any leftover in Irom0text.bin's 768 KB space)
3F C000 - 3F FFFF = System Param  (16 KB)

This seems contrary to what is currently being created and flashed (i.e., NodeMCU currently flashes Irom0text.bin to 0x10000). Is this just a red herring, and it doesn't matter where files actually get flashed (assuming that the linker script correctly sets up the start address)?

When we get into toolchain configuration and linker scripts, I quickly get over my head, so that's why I'm bringing the issue to the folks here with more experience. I'm not sure how to troubleshoot the issue at this point.

Note: As I submit this post, I am building a second toolchain on a different machine to make sure that my first one just isn't corrupted somehow, which is always a possibility.

- Sat Feb 13, 2016 10:58 pm #41078 Setting up another build environment changed the outcome! I get successful binaries now (or at least my first big one was successful).

My first (failing) build environment was on a Raspberry Pi 2 running Raspian.... an ARM architecture.

My second (successful) build environment was on an Ubuntu VM running in Azure.... an x64 architecture.

Could it be that my RaPi2 environment somehow got corrupted? Maybe. But at the moment, my gut tells me that there's something off in the toolchain on ARM and that's why nobody else (using x86/x64) could reproduce.

- Sun Feb 14, 2016 6:11 pm #41125 Hi, even if you use an M$ VM, most of this still applies: How to setup a VM to host your toolchain. The main advantage of using an Ubuntu 12.04 LTS VM is the that toolchain tarball in the repo tools folder can just be unpacked. This takes a few seconds and your don't need to build the toolchain.

If you use a server build then you can simply PuTTY a number of SSH sessions onto the VM to do you console sessions. I would also imagine that you can use a shared folder or an SSH browser to do your editing in your favourite Windows program editor.

When it comes to getting your head around Github, StackOverflow will explain most of the tricks.

Please see my Developer FAQ for Q&A on nodeMCU Lua before asking a question here that's already been answered. This and the other official documentation should be your first reference for developing Lua Apps