ESP8266 Community Forum

- Mon Oct 06, 2014 3:45 am #1276

Help anyone? I am able to compile the AT example but when I try to compile the IoT_Demo I get a lot of the following undefined references:

And a couple more refering to undefines refernce to `espconn_secure_*....'

So obviously I'm missing a reference to a json lib, but not quite sure where.

Thanks!

Can you share the makefile you are using?
Make sure you link against json and ssl libraries from the SDK.

- Mon Oct 06, 2014 6:22 am #1285 I have a question that maybe jcmvbkbc (or someone else) can shed some light on. Last night i was poking around with directly accessing the registers that set/read the GPIO pins. As you may have noticed, there is an IDA plugin linked to at viewtopic.php?f=13&t=214#p1247 that allows to load Xtensa binary files for that core into IDA Pro.

Now, in the eagle_soc.h include file, the base address to the GPIO registers is given as 0x6000.0300, and indeed, using the registers in that range (0x6000.0304, 0x6000.0308, 0x6000.0310 and 0x6000.0314) that allows direct access. However, putting the dump of the internal ROM into IDA, and looking at the disassembly for the "gpio_output_set" function, gives this code:

Code: Select allROM:40004CD0 gpio_output_set:                        ; CODE XREF: gpio_init+26p
ROM:40004CD0                                         ; gpio_intr_test+17p ...
ROM:40004CD0                 l32r            a6, dword_40000FC4
ROM:40004CD3                 memw
ROM:40004CD6                 s32i            a2, a6, 4
ROM:40004CD9                 memw
ROM:40004CDC                 s32i            a3, a6, 8
ROM:40004CDF                 memw
ROM:40004CE2                 s32i            a4, a6, 0x10
ROM:40004CE5                 memw
ROM:40004CE8                 s32i            a5, a6, 0x14
ROM:40004CEB                 ret.n
ROM:40004CEB ; End of function gpio_output_set


The value at dword_40000FC4 is 0x6000.0200. Strange thing is that calling this function works as expected, while accessing the registers in that range (which would end up as 0x6000.0204, 0x6000.0208, 0x6000.0210 and 0x6000.0214, if i am reading the code right) causes an exception.

What am i missing here? Is there something else going on that will add an offset of 0x100 to end up at the right address? Or does the plugin interpret a few things wrongly? The stored dword in the ROM for the base is really 0x6000.0200, i double cheecked.

Greetings,

Chris

- Mon Oct 06, 2014 6:36 am #1286

Now, in the eagle_soc.h include file, the base address to the GPIO registers is given as 0x6000.0300, and indeed, using the registers in that range (0x6000.0304, 0x6000.0308, 0x6000.0310 and 0x6000.0314) that allows direct access. However, putting the dump of the internal ROM into IDA, and looking at the disassembly for the "gpio_output_set" function, gives this code:

Code: Select allROM:40004CD0 gpio_output_set:                        ; CODE XREF: gpio_init+26p
ROM:40004CD0                                         ; gpio_intr_test+17p ...
ROM:40004CD0                 l32r            a6, dword_40000FC4
ROM:40004CD3                 memw
ROM:40004CD6                 s32i            a2, a6, 4
ROM:40004CD9                 memw
ROM:40004CDC                 s32i            a3, a6, 8
ROM:40004CDF                 memw
ROM:40004CE2                 s32i            a4, a6, 0x10
ROM:40004CE5                 memw
ROM:40004CE8                 s32i            a5, a6, 0x14
ROM:40004CEB                 ret.n
ROM:40004CEB ; End of function gpio_output_set


The value at dword_40000FC4 is 0x6000.0200. Strange thing is that calling this function works as expected, while accessing the registers in that range (which would end up as 0x6000.0204, 0x6000.0208, 0x6000.0210 and 0x6000.0214, if i am reading the code right) causes an exception.

What am i missing here? Is there something else going on that will add an offset of 0x100 to end up at the right address? Or does the plugin interpret a few things wrongly? The stored dword in the ROM for the base is really 0x6000.0200, i double cheecked.

I see no magic in this code, so most probably the plugin calculated literal address incorrectly. Can you compare IDA output with objdump -d output?

- Mon Oct 06, 2014 7:23 am #1289

I see no magic in this code, so most probably the plugin calculated literal address incorrectly. Can you compare IDA output with objdump -d output?

Unfortunately not, since this is the code dump of the internal ROM. It's not available as an object file.

The 32 bytes for that function (including the 0-byte padding) are:

Code: Select all4000:4CD0 61 BD F0 C0  20 00 22 66  41 C0 20 00  32 66 42 C0
4000:4CE0 20 00 42 66  44 C0 20 00  52 66 45 0D  F0 00 00 00


The bytes around (and including) the dword_40000FC4 are:

Code: Select all4000:0FB4 10 0D F0 00  D0 DC FF 3F  31 FF FF 29  03 0D F0 00
4000:0FC4  00 02 00 60  A0 D6 FF 3F  74 D6 FF 3F  B8 D6 FF 3F
4000:0FD4  C0 D6 FF 3F  E0 17 00 40  78 18 00 40  DC D6 FF 3F


There is no sequence of "00 03 00 60" in the whole thing, and as you can see, 4000:0FC4 indeed holds "00 02 00 60". So i'm really curious what the issue may be.

Greetings,

Chris