OTA and slot 0

[albertoa]

I'm probably doing something wrong, but I'm stuck.

I have my own code that updates the flash area of the firmware for OTA updates.

It uses the spi_flash... functions from the 1.4.1 SDK to erase and write the flash sectors.

Using an ESP-1 module I write the fw to 0x2000 (slot 0) and 0x42000 (slot 1) (linked with their own corresponding linking script) with esptool.py

That goes well. I can then switch between them and both copies of the fw work.

If I run from slot 0 I can then erase and write fw to slot 1 and switch with no problems.

If I run from slot 1 when I try to erase slot 0 I think the memory gets corrupted. It doesn't finish the erase and I get:

Erasing 56 sectors starting with 0x2

ets Jan 8 2013,rst cause:4, boot mode:(3,0)

wdt reset load 0x40100000, len 1580, room 16 tail 12 chksum 0xbf ho 0 tail 12 room 4 load 0x3ffe8000, len 724, room 12 tail 8 chksum 0x9f csum 0x9f

rBoot v1.2.1 - richardaburton@gmail.com (modified) Flash Size: 4 Mbit Flash Mode: QIO Flash Speed: 40 MHz

Booting rom 1. Fatal exception (0): epc1=0x4028298c, epc2=0x00000000, epc3=0x00000000, excvaddr=0x00000000, depc=0x00000000 Fatal exception (0): epc1=0x4028298c, epc2=0x00000000, epc3=0x00000000, excvaddr=0x00000000, depc=0x00000000 Fatal exception (0): epc1=0x4028298c, epc2=0x00000000, epc3=0x00000000, excvaddr=0x00000000, depc=0x00000000 Fatal exception (0):

Unless I am miscalculating the flash sectors I don't see how this would happen.

This is on a ESP-1 so I'm assuming 512KB flash.

Any suggestions on what I should look at?

Thanks,

Alberto

[raburton]

If I run from slot 1 when I try to erase slot 0 I think the memory gets corrupted. It doesn't finish the erase and I get: Erasing 56 sectors starting with 0x2 ets Jan 8 2013,rst cause:4, boot mode:(3,0) wdt reset

A reset when erasing like this usually means you've tried to erase running code. Perhaps rom1 is using the irom segment in the first half of the chip (the one intended for rom0), because rom1 isn't linked correctly.

epc1=0x4028298c

This program counter is out of the range of a 512k flash (> 0x40280000). Again it suggests that the programs are not correctly linked, but this then no part of your code should be that high so it may simply be corruption. The fact that rom1 no longer works when you've part erased rom0 also suggests that rom1 is trying to access something in the wrong part of flash (most likely the irom segment of rom0).

Can you post the top part (section information) of your 2 ld files.

[albertoa]

To be honest I never did ld scripts before, wouldn't surprise me I messed them up. Tried to follow your tutorial but I may have been confused. Here are the 2 sections:

rom0.ld

MEMORY { dport0_0_seg : org = 0x3FF00000, len = 0x10 dram0_0_seg : org = 0x3FFE8000, len = 0x14000 iram1_0_seg : org = 0x40100000, len = 0x8000 irom0_0_seg : org = 0x40202010, len = 0x3C000 }

rom1.ld

MEMORY { dport0_0_seg : org = 0x3FF00000, len = 0x10 dram0_0_seg : org = 0x3FFE8000, len = 0x14000 iram1_0_seg : org = 0x40100000, len = 0x8000 irom0_0_seg : org = 0x40282010, len = 0x3C000 }

[raburton]

The rom1 irom0_0_seg address of 0x40282010 is too high, it's more than 512k into a 512k flash chip i.e. it's not actually on the flash chip at all! You need to use 0x40242010 to be half way into a 512k flash. My guess is the read is wrapping so you are using the first copy of the irom section when you try to read the one off the end of the flash.

Also, how big is your rom? If you are trying to fit two roms on a 512k flash it's going to be tight, starting at 0x42000 you can only go up to 0x7c000 (the last 4 sectors are used by the sdk to store settings), which means a max rom size of 237,568 bytes.

[albertoa]

Thanks, I should of caught that.

Right now my irom size is 188532. I need to add a bunch of code so it will grow. All I need is UDP, so I'll work on making the network stack minimal now that this hurdle is over. If it gets hard, I'm likely to just move to ESP-12 and not support 512K flash sizes.

One last question. Where does the SDK get the pointer to its config area (the 0x7c000)? Since rboot handles arbitrary sizes (max at 8mbit mapped at a time) would the last 4 sectors apply per 8mbit block or does it query the flash chip to get its size and always use the last 4 physical sectors? I couldn't find any reference in the sources.

[raburton]

The size of the flash is written in the first few bytes, this is embedded in the first bytes of the app (in your case rBoot) when you write it, either as part of the binary file, or more commonly this is overridden by the flasher, based on the flash size you specify. E.g. regardless of the size byte in the binary if you use esptool.py it will set that byte based on the -fs parameter (or it's default if not specified). The SDK always uses the last 4 sectors of the flash, based on this size byte (if you set the size byte wrong then the sdk won't know that, and it's idea of the last 4 sectors will be incorrect).

[albertoa]

Great thanks. I'm closing the issue as I can confirm the problem was me messing up the irom vector.

With the sysparam area being tied to the SDK version I wonder if the size trick will be needed for firmware that uses different SDKs. But that's for a different discussion.