ESP8266 Community Forum

Did anyone generate a map file when rebuilding the IOT demo?

I am in contact with Espressif and they are being helpful. They have commissioned English translations of everything and are sending me the docs for review as they work on them. But so far they've only translated the Beginner's Guide which isn't very useful.

I'm a little confused but I believe these is a new version of the chip that is almost ready to ship - ESP8266EX. Only difference I know of is that it has two serial ports. ESP8266EX is also rated at 125C. Not clear if the ESP8266EX is a replacement or if they will ship both.

Squonk wrote:A simple test would be to write and read back at 0x40000000: if you can't, good chance is that it is ROM

Tried that; it is indeed read-only.

Squonk wrote:...or at least it is what is described in the ROM ld include script...

Yeah, the point I wanted to make is that the linker scripts only provides hints on where to look, sizes and type (RAM/ROM) should probably be determined by observing the hardware
I believe you are right in your theories. XTCOM have command for writing to RAM and SPI Flash, I'll try to re, document and implement them as well.
MAC seems to be stored in OTP ROM on chip, by judging from the symbol read_macaddr_from_otp in app_main.o in libmain.a, so it won't be lost when reflashing the firmware.

12Mhz is fairly slow for SDIO normal SDIO can run 50Mhz. But 12Mhz may be good enough.

If the theories about page faulting from the flash are true, the later activity you see should be 4KB page reads. So at 12Mhz * 4KB * 8 / 4 lines = 680us to handle a page fault.

Ok, large part of relevant discussion happened in "Firmware Dump" thread: viewtopic.php?f=6&t=39 (and irrelevant discussion on SPI speed happened here - gotta love forums!). Anyway, based on analysis of external FlashROM dump provided there, and builtin ROM dump provided here, following conclusions can be made aboute the memory map:

0x40000000 (64K) - ESP8266 builtin ROM. It appears to be truly builtin, as its content doesn't appear in external FlashROM dump. The ROM technology is unclear. It can be mask ROM, or OTP, or just flash ROM whose means of programming are yet to be discovered. As more dumps for different modules will be collected, we'll be able to differentiate these choices.

0x40240000 - at this address irom0_0_seg memory segment is located, which in turn consists of .irom0.text sections, which are used in static libraries as provided in esp_iot_sdk_v0.6.zip . Data for this segment is contained at offset 0x40000 in external FlashROM. However, if you match memory map address and offset, it drags you to do some leap of faith and just tell:

0x40200000 - at this address, external SPI flash in mapped, unconfirmed. In particular, at 0x40240000 there's irom0_0_seg which contains library routines from SDK. At 0x40200000 there would be user application, but it is actually:

0x40100000 - User application from 0x40200000 gets shadowed here, which is Instruction RAM (size 32K). Shadowing supposedly happens for speed (and to be able to override interrupt vectors).


Risks and challenges:

1. All this information is based on the dumps provided by 3rd parties. They may be incorrect or erronuous.

2. kongo, provider of builtin ROM dump, reports that reading 0x40200000 and up returns zeroes (but then who are you to read my app? ever heard of vendor flash protection?)

3. Demo app from SDK was built and posted here, and sizes more than 32K, and thus won't fit into (provided by vendor) I-RAM size. But then it is surprisingly segfaults on execution.

4. FlashROM dump from 0x40000 doesn't contain nay ascii string, which is highly suspicious.

5. Other people bring in MMUs, unicorns, and dragons into the picture. But that apparently only makes Occam laugh.