ESP8266 Community Forum

- Mon Aug 03, 2015 8:30 am #24895 Thanks Richard...I tried that but get the following errors...what am I missing? I can't seem to find where Cache_Read_Disable is...is it in the SDK? Not sure why its undefined.

Code: Select allC+ app/rboot-bigflash.cpp
app/rboot-bigflash.cpp: In function 'void Cache_Read_Enable_New()':
app/rboot-bigflash.cpp:26:22: error: 'Cache_Read_Disable' was not declared in this scope
   Cache_Read_Disable();
                      ^
app/rboot-bigflash.cpp:28:72: error: 'SPIRead' was not declared in this scope
   SPIRead(BOOT_CONFIG_SECTOR * SECTOR_SIZE, &conf, sizeof(rboot_config));
                                                                        ^
app/rboot-bigflash.cpp:36:60: error: 'ets_printf' was not declared in this scope
   ets_printf("mmap %d,%d,1\r\n", rBoot_mmap_1, rBoot_mmap_2);
                                                            ^
app/rboot-bigflash.cpp:39:49: error: 'Cache_Read_Enable' was not declared in this scope
  Cache_Read_Enable(rBoot_mmap_1, rBoot_mmap_2, 1);
                                                 ^
make: *** [out/build/app/rboot-bigflash.o] Error 1

- Mon Aug 03, 2015 8:54 am #24898 These are functions in rom. If you look in the ld file you'll see at the bottom another file that gets included, that contains all the addresses of these functions for the linker. As you seem to be failing before that at the compiler step you'll either need to disable errors on implicit function declarations or just stick an extern definition for the functions in the c file/ suitable header file.

e.g.

Code: Select allextern void SPIRead(uint32 sector, uint8 *buffer, uint32 length);

- Sun Aug 16, 2015 7:48 pm #26226 Hi Richard -

I took your earlier advice about using BOOT_BIG_FLASH to re-map 1MByte slots into x40200000. I've been playing around with integrating this in with Sming on an ESP-12 with a 4MByte flash with two slots. One slot is stored in the lower region of the flash and the other in the upper half, e.g.

0x00000 $(FW_BASE)/rboot.bin
0x02000 $(FW_USER_OUT)
0x202000 $(FW_USER_OUT)

As you mentioned, I can use a single linker file and create a single image for both regions since they're re-mapped to the correct start address (0x40200000). This seems to work great . . . I've successfully toggled between both slots.

I'm having trouble, however, getting the OTA part working reliably. Basically, I seem to be having two issues:

* Early termination of the HTTP transfer due to unknown reasons. It's either my environment, something fishy in Sming or the 1.2.0 SDK but the HTTP transfer appears to be unreliable (e.g. typically timeouts).

* Lock-up in rboot-ota.c:~133:spi_flash_erase_sector(2). Occasionally it will lock-up here and the WDT kicks attempting a reboot. Unfortunately I then see a storm of exceptions and ultimately I have to re-flash the chip with esptool.py to recover. It seems to always hang (when it does) while erasing sector 2.

I've actually had it flash and reboot successfully but that's a rare occurrence. Mostly I can't transfer the image and when it does transfer it's likely to hang in spi_flash_erase_sector().

I was just wondering if you've noticed any flakiness in your testing. I'm using the latest Sming (from master) with the 1.2.0 SDK. Looks like you do most of your development work using the bare SDK.

FYI - It looks like it will be tough making SPIFFs work (as integrated with Sming). The start of the SPIFFs file system is calculated based on the _flash_code_end in the Sming linker file. Since the same rom is used for both slots, this address is always the same which means both slots share the same SPIFFs file system region. Not what you typically want when you have two separate rom binaries . . . they each should use their own file system area. Wish there was some way to map *both* the application rom and SPIFFs file system region when the slots are selected at boot. Would you have any suggestions?

Thanks . . .

- Mon Aug 17, 2015 5:50 am #26253 I'm at work so can't look at this properly right now, but a few thoughts off the top of my head...

Are the failed transfers simply due to timeout? Might be especially likely if you are transferring large images with embedded filesystems. Does increasing the timeout in the ota code help at all? At the moment the code has a single timeout from connection to completion, but that might not be all that good an idea. I have considered resetting the timeout on each receive, that way as long as the update is making progress it will continue without an limit on the total time taken.

The erase problem I don't understand, sector 2 is probably the first sector it is trying to erase, so it hasn't even got very far at that stage.

As for the spiffs location, isn't this access by memory mapped flash (rather than spi read calls)? If so there is no problem. It'll be in the same 1mb chunk as the code, each of which gets mapped to the same address range in memory, so it will read the correct one.