ESP8266 Community Forum

- Wed Aug 19, 2015 7:17 am #26453 Hi Richard -

I've tried undefining the symbol (-u Cache_Read_Enable_New) in the LDFLAGS and re-arranging the link order. No appreciable effect. Also tried including the function in my "main" C file . . . again no effect. The thing to remember, however, that this is a Sming environment so there is no simple 'C' file entry point but it is rather buried in the Sming library. The C++'isms add all kinds of warts that required me to make some modifications (mostly trivial) to get your code to compile in a C++ environment (e.g. mostly extern "C" around headers etc... and Sming's tendency to re-state all the primitive SDK APIs so they're compatible with C++). I obviously can tell you do your rboot development in a bare-bones Expressif SDK environment without the bells/whistles of something more heavyweight like Sming (or the Arduino alternative). Pros/Cons to each approach and certainly easier (for your application) to stay in a pure SDK environment. Can't blame you there but it make integration of rboot a little more "challenging" in the world of C++ frameworks

I'd be interested to see the order of your link command-line. Maybe I can sort something out there. Also, I suspect I may need to go down the path of fiddling with ROM linker file so it points at a provided Cache_Read_Enable() and take the hit by chewing up more iram. Hopefully, since it's a wrapper function, the hit would be fairly small. Can you offer more details there?

Anyway, I appreciate the continued support/help. Hopefully I'll eventually get this licked. Have you tried the BIG_FLASH option with a simple Sming-based project? Does it work for you?

Thanks . . .

- Wed Aug 19, 2015 12:49 pm #26495 These are my linker lines, note APP_AR containing the app objects is before LIBS, normally they would be the other way around. Also note -u Cache_Read_Enable_New. This works for me, on normal apps, I must admit I haven't tested big flash on sming apps, but will endeavour to do so as soon as I get a chance (sorry, won't be tonight).

LDFLAGS = -nostdlib -Wl,--no-check-sections -u call_user_start -u Cache_Read_Enable_New -Wl,-static
LIBS = c gcc main2 hal phy net80211 lwip wpa pp upgrade
@$(LD) -L$(SDK_LIBDIR) $(LD_SCRIPT_U1) $(LDFLAGS) -Wl,--start-group $(APP_AR) $(LIBS) -Wl,--end-group -o $@

- Wed Aug 19, 2015 5:26 pm #26522 Hi Richard -

I tried your changes. Here's my LIBS and LDFLAGS:

Code: Select allLIBS           = microc microgcc main2 hal phy pp net80211 lwip wpa sming $(EXTRA_LIBS)
LDFLAGS       = -nostdlib -u call_user_start -u Cache_Read_Enable_New -Wl,-static -Wl,--gc-sections


And link line:

Code: Select all$(LD) -L$(PROJ_LIBDIR) -L$(USER_LIBDIR) -L$(SDK_LIBDIR) $(LD_SCRIPT) $(LDFLAGS) -Wl,--start-group $(APP_AR) $(LIBS)  -Wl,--end-group -o $@


So I linked it and now I see:

Code: Select allxtensa-lx106-elf-objdump -t out/build/app.out | grep Cache_Read_Enable_New
40105048 g     F .text   00000063 Cache_Read_Enable_New


Unfortunately, this still doesn't seem like the right one and is further shown when I try to boot it and I see the rboot preamble followed immediately by:

Code: Select allFatal exception (0):
epc1=0x40202024, epc2=0x00000000, epc3=0x00000000, excvaddr=0x00000000, depc=0x00000000


By the address that seems like it's dying in my application code (rom0). So I think rboot is doing it's thing but the mapping code is not correct. This occurs whenever I switch between "$(LIBS) $(APP_AR)" and "$(APP_AR) $(LIBS)" in the link line.

Still doing further investigation. Hope you have time at some point to either confirm or refute my findings with Sming. Either way I'm sure I'll learn something along the way. Thanks for the help and suggestions.

- Wed Aug 19, 2015 8:14 pm #26527 Hi Richard -

I've made a little progress. I placed $(APP_AR) before $(LIBS) and told the linker to generate a map file and realized that it was throwing the exception in os_printf(). I saw in your implementation you used ets_printf() instead to display the map setting. In Sming, it's fairly common to use debugf() (which maps to os_printf) so I made the substitution when compiling my version of Cache_Read_Enable_New(). Apparently, os_printf() isn't quite set up when this function is called. I replaced debugf() with ets_printf() and viola, the app boots and I can switch between rom0/1 using the OTA update mechanism without suffering any lock-ups or crashes! Amazing! Plus, I can now verify (also from inspection of the map file) that the applications version of Cache_Read_Enable_New() is being called in iram.

Unfortunately, I still have issues with SPIFFs. If I load some empty files in the "files" folder SPIFFY will generate a spiff_rom.bin which I flash to the same location specified in the original Sming makefile. It's here:

rom0

Code: Select allSPIFF_START_OFFSET = $(shell printf '0x%X\n' $$(( ($$($(GET_FILESIZE) $(FW_USER_OUT)) + 16384 + 36864) & (0xFFFFC000) )) )


and for the second rom (rom1) I use the following:

Code: Select allSPIFF_START_OFFSET2 = $(shell printf '0x%X\n' $$(( ($$($(GET_FILESIZE) $(FW_USER_OUT)) + 16384 + 36864 + 2097152) & (0xFFFFC000) )) )


I offset the SPIFFS filesystem by 2MBytes (2097152) to place it in the upper region of the flash where rom1 resides (but above it).

When I list the files while it's running they're typically garbled (e.g. part of the names are chopped off). If I create files while the program is running and list them then they look all right. Also, it seems the SPIFFs rom is being shared (or viewed) by both roms which is a problem. I suspect my placement of the SPIFFs file system is wrong or it's somehow (not) being mapped when switching between roms. Any suggestions you might have would prove helpful.

Slowly but surely I'm getting there . . . with your help of course