ESP8266 Community Forum

- Sun May 03, 2015 6:02 am #16339 I got the same problems when I tried to compile u8glib.
In the meantime: which display did you get to work with the adafruit library? I have one of those dirt cheap displays with i2c interface and only for pin connector (just sda, scl, gnd and vcc). But I wasn't succesful..

http://blog.squix.ch

- Sun Sep 13, 2015 4:49 am #28962 I'm having similar issues with ucglib and the problem is indeed font data. (BTW, NodeMCU manually stripped out from source code all except a few of the fonts; I'm hoping to avoid this)

Input from true experts would be appreciated. Here's my current understanding:

Each font in ucglib (and u8glib) is simply a const char fontname[] array, and there are hundreds of those, a few KB each. On AVR, the code does not place all fonts in the .progmem section, but rather places each in a section of it's own, .progmem.fontname.

On the ESP, I first tried placing all font data in .irom.text, but that leads to the error stated in the OP. It appears that the linker does not strip unreferenced global arrays (I verified this via objdump on the ELF output).

I then mirrored the approach from AVR, and placed each font data array into a section of it's own, .irom.text.fontname. Now unreferenced sections do get stripped out (objdump confirms), and the executable fits in memory.

However, these extra sections are not copied over from the .elf file to the .bin file by esptool. So, I added extra -bs arguments for each of those sections (manually, for now).

Here's where I'm getting stuck: if the program uses one font, and I add just that one section (eg -bs irom.text.fontname ), everything works great. However, if the program uses more fonts, and I add more than one such sections (eg -bs .irom.text.fontname1 -bs .irom.text.fontname2 ), then I get a fatal exception (28):

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


which keeps repeating in an infinite loop. FWIW, this is immediately after flashing; if I power-cycle the ESP, then on next boot it seems to get stuck at the bootloader (I need to remember how to set the non-std baud to read what it's saying -- I can, if you think it'll be useful).

EDIT: I dug up the setserial incantation yet again (for anyone else looking for it: setserial /dev/ttyUSB0 spd_cust divisor 320, then open at 38400 -- this divisor value is for FTDI), and it just says more of the same at boot:

Code: Select all ets Jan  8 2013,rst cause:1, boot mode:(3,6)

load 0x4010f000, len 1264, room 16
tail 0
chksum 0x42
csum 0x42
~ld
sp 0x3fffeac0
epc1=0x40001800, epc2=0x00000000, epc3=0x00000000, excvaddr=0x0304004f, depc=0x00000000
Fatal exception (28):
epc1=0x40001800, epc2=0x00000000, epc3=0x00000000, excvaddr=0x00007ff0, depc=0x00000000
Fatal exception (28):
epc1=0x40001800, epc2=0x00000000, epc3=0x00000000, excvaddr=0x00007ff0, depc=0x00000000
Fatal exception (28):
epc1=0x40001800, epc2=0x00000000, epc3=0x00000000, excvaddr=0x00007ff0, depc=0x00000000
...


- Sun Sep 13, 2015 10:22 am #28974 Nevermind, solved!! First a quick "proof" (FPS example sketch: text 5.2, box 4.4, gradient 4.1):



For those interested, please see https://github.com/spapadim/ucglib (and if you try, please let me know how it went). You'll also need to apply these simple patches to your Arduino ESP install: https://gist.github.com/spapadim/a4bc258df47f00831006

Details: Had failed to notice the extra section was in a random place in the memory map (sleeping on it helped me see the obvious ) -- so, messing with esptool -bs was stupid, I just needed to tweak the linker script to add the extra sections in the .irom0.text output section.