Espressif 1.10 SDK Experience

Peter ScargillUncategorized15 Comments on Espressif 1.10 SDK Experience

Update 04/June/2015

I must say I cannot really gripe about support from Espressif…….  I received an email this morning to ask me to use another FLASH tool – that failed – same result – code compiled under the old 1.01 SDK worked – code compiled under 1.10 SDK failed. Eventually, a fellow called Wu Juan Gang came back to me – he had spotted that I was not using the eagle.app.v6.ld file that came with the new SDK – but the original – he sent me an update and I substituted that – sure enough – both projects worked first time. I would say that’s down to my incompetence but as I’ve no idea what that file does we’ll just leave it as another mystery resolved.

Hence, I can state that two large projects work just fine with the new SDK 1.10 from Espressif and my thanks to them for their support!!

Original blog entry:

I’m not having a lot of luck with the new SDK. 

Previous to this I was using 1.01 and that worked fine – though I did run out of RAM for storing functions at one point… and had some help – and all was well… now, nothing – when I try to run either of my 2 lots of C code based on TuanPMs MQTT code  – all I get is a bunch of  characters flying out of the serial port.

So firstly and this might be of help to others – some helpful info from Espressif…

 

1.Remove some useless APIs from os_api.h, such as
CODE: SELECT ALL
diff -r esp_iot_sdk_v1.0.1/include/osapi.h esp_iot_sdk_v1.1.0/include/osapi.h
39,41d31
< #define os_timer_done ets_timer_done
< #define os_timer_handler_isr ets_timer_handler_isr
< #define os_timer_init ets_timer_init
45d34
< #define os_update_cpu_frequency ets_update_cpu_frequency

2.Remove interrupt related APIs below from os_api.h, please use APIs in ets_sys.h instead
CODE: SELECT ALL
diff -r esp_iot_sdk_v1.0.1/include/osapi.h esp_iot_sdk_v1.1.0/include/osapi.h
#define os_intr_lock ets_intr_lock
#define os_intr_unlock ets_intr_unlock
#define os_isr_attach ets_isr_attach
#define os_isr_mask ets_isr_mask
#define os_isr_unmask ets_isr_unmask

3.Remove GPIO pull-down function from eagle_soc.h
CODE: SELECT ALL
#define PERIPHS_IO_MUX_PULLDWN          BIT6
#define PERIPHS_IO_MUX_SLEEP_PULLDWN    BIT2
#define PIN_PULLDWN_DIS(PIN_NAME)             CLEAR_PERI_REG_MASK(PIN_NAME, PERIPHS_IO_MUX_PULLDWN)
#define PIN_PULLDWN_EN(PIN_NAME)              SET_PERI_REG_MASK(PIN_NAME, PERIPHS_IO_MUX_PULLDWN)
Note:
There are no pull-down functions on GPIO pad now, so we should never use these registers.
Add external resistance to pulldown the pin.

That was very nice of them… trivial stuff but handy to know!!

But my code will compile – but not run.  For anyone wanting a challenge…

So I am running a variation of the TuanPM MQTT code…  the MAKEFILE lets me put my code at 0x20000 and store non-volatile variables sector 0x78 as against 0x3c.

It all works well on older SDKs (including 1.01) but will not work at all on SDK 1.10

Here are the results of compiling the C code – if anyone is a whiz at reading the status data – feedback would be appreciated as this is a pain in the backside…

SDK 1.01

build/app.out:     file format elf32-xtensa-le

Sections:
Idx Name          Size      VMA       LMA       File off  Algn
  0 .data         00000970  3ffe8000  3ffe8000  000000e0  2**4
                  CONTENTS, ALLOC, LOAD, DATA
  1 .rodata       000016f0  3ffe8970  3ffe8970  00000a50  2**4
                  CONTENTS, ALLOC, LOAD, READONLY, DATA
  2 .bss          00009848  3ffea060  3ffea060  00002140  2**4
                  ALLOC
  3 .text         0000734a  40100000  40100000  00002140  2**2
                  CONTENTS, ALLOC, LOAD, READONLY, CODE
  4 .irom0.text   0003221c  40220000  40220000  00009490  2**4
                  CONTENTS, ALLOC, LOAD, READONLY, CODE
——————————————————————————
FW firmware/eagle.flash.bin
FW firmware/eagle.irom0text.bin

The above DOES work…

SDK 1.10

build/app.out:     file format elf32-xtensa-le

Sections:
Idx Name          Size      VMA       LMA       File off  Algn
  0 .data         00000550  3ffe8000  3ffe8000  000000e0  2**4
                  CONTENTS, ALLOC, LOAD, DATA
  1 .rodata       00001698  3ffe8550  3ffe8550  00000630  2**4
                  CONTENTS, ALLOC, LOAD, READONLY, DATA
  2 .bss          000096f0  3ffe9be8  3ffe9be8  00001cc8  2**4
                  ALLOC
  3 .text         000075e6  40100000  40100000  00001cc8  2**2
                  CONTENTS, ALLOC, LOAD, READONLY, CODE
  5 .irom0.text   00032acc  40220000  40220000  000092c0  2**4
                  CONTENTS, ALLOC,

LOAD, READONLY, CODE
——————————————————————————
FW firmware/eagle.flash.bin
FW firmware/eagle.irom0text.bin

The above does NOT work.

Any ideas guys??

15 thoughts on “Espressif 1.10 SDK Experience”

  1. Hi Peter,

    Can you send me the new ld file by email, please ? I want to do a diff with what I have. At the first look all my eagle.app.v6.ld are the same from 0.9.5 to 1.1.0

    Thanks

  2. As you will see guys, the problem is solved and I’ve updated the blog – was using the wrong eagle.app.v6..ld – I’ve gone further now and dropped the code base to 0x10000 – and though I’m waiting for feedback from Espressif as to why when they helped me, they specified a really weird length for the iron_o_seg, it does work… so I’ve reduced the wasted space immensely. Just need to get that RAM use down just a little more…

  4. On a related note, Espressif have released an updated documentation package with a new datasheet (v4.3).

    http://bbs.espressif.com/download/file.php?id=439

    This is a much easier read than the early versions and contains some nice, simple tables listing pin usage by function (that is, instead of having one humongous, confusing table with a gazillion columns, they have separate tables for each function with only the required pins listed; so for instance, the I2C table only has details on two pins).

    The English is much improved and a lot of the ambivalent wording has gone. I haven’t checked all of the other manuals in the documentation package, but judging by the datasheet I would say it’s definitely worthwhile downloading the whole package.

    http://bbs.espressif.com/viewtopic.php?f=21&t=225

    -John-

    1. That’s a bit more like it. Now if I can just figure out how to apply that new patch…

    2. Thanks John, the new docs are good.

      I too get bit every time I change something (SDK, framework) so for the moment I’m staying with a (mostly) working setup so I can actually do some development instead of problem-solving.

      Pete – you’ve taken the Espressif oath… has it brought you a better level of documentation and support (besides the nifty eval board)?

      1. Erm, well, I got some info from them – but I think most of that is now common knowledge – I think they’ve changed and become more open – I can understand how they’d be wary of giving too much away at first, after all they have come up with a winner. I don’t know what started it but at least I have a dialog with Espressif now. After a couple of false starts this morning (they couldn’t handle Dropbox then I sent an empty file) they now have my code that doesn’t work – so I’m sitting here praying that they’re going to find out why – clearly the first 1.10 code wasn’t right as they openly admitted that the SPI could cause an issue and to be fair they patched that quickly – I’m just hoping it’s a bug that’s stopping my code working and that they can identify that. We have moved the starting point to 0x20000 to give lots more FLASH space and I’m hoping the fellow that helped me when he’s back from hols can stretch this even further. As you get more ambitious, I’m thinking that RAM is going to be the next issue but we’re (hopefully) not at that point yet. My problem is I don’t really understand the RAM – I don’t know if the RAM you use for variables is completely different to the RAM used for routines etc… words like iRAM don’t help and the memory mapping isn’t entirely clear to me either – but very slowly the fog is starting to lift.

      2. I’ve realised that at least with the 1.11 sdk – in the docs folder is up to date documentation in English.

  5. I’ve instaledl on a different VM the esp-open-sdk (which contains the latest SDK 1.1.0 and the latest patch) and I’ve migrated my project to it. No chance on make it working.

  6. I have the same problem migrating to 1.1.0. I’ve managed to correct the code to be able to compile it but what I can see on the serial is just rubbish ( possible memory errors).

    So, Peter I guess that is not the code, is more on where the code is written into the memory. I don’t have an account on bbs.espressif.com to ask there for help, so I will still try to manage myself. I’ll let you know if I have a solution. I am writing the code at 0x0 and 0x40000.

    1. There is a patch… but no instructions as to how to apply it for the dimmer folk like me…

    2. Well, I applied the patches (3 of them, after renaming and over-writing the relevant .a files in /lib directory) – made no difference at all – my files compile and run under 1.01 and earlier – but compile and DON’T run under 1.10 – continuous stream of characters out of the serial line…

      Back to square one.

Comments are closed.