ESP8266 Developer Zone

Re: How can I REALLY tell which userX.bin is currently executing ?

2016-02-02T17:10:41+08:00

Yes, you can do that, but you cannot tell where it really is executing; you will only get the #define value from compile time.

On an x86, you would do it like this :

Code:

                  CALL some_label
some_label:       POP EAX
                  ; EAX now holds the address of the "some_label" location

But it's a very long time since I've written assembler code, so I'm a bit rusty and not very sure about how it can be done on modern architectures

Statistics: Posted by sharkx — Tue Feb 02, 2016 5:10 pm

Re: How can I REALLY tell which userX.bin is currently executing ?

2016-02-01T23:56:30+08:00

Sharkx;

We can know what app is running....

put in the makefile, in the cflags line this:

-DAPP=$(APP)

this will reflect this var (APP) in the c code....

Then we can test inside software:

uint8_t ICACHE_FLASH_ATTR slotBinCheck(){
return APP;
}

Again...I not test this solution but it is on way...

att;

Juliano

Statistics: Posted by jkvarela — Mon Feb 01, 2016 11:56 pm

Re: How can I REALLY tell which userX.bin is currently executing ?

2016-02-01T20:44:57+08:00

I still need because I will use the memory area for downloading other files while I'm not using to update. I do not have any reliable method to determine which portion of memory that I'm working, there must be some way to determine this, perhaps reading some register of remmaping or another way ... anyone have any other way?

Thanks;

Juliano

Statistics: Posted by jkvarela — Mon Feb 01, 2016 8:44 pm

Re: How can I REALLY tell which userX.bin is currently executing ?

2016-02-01T02:25:11+08:00

Well... it doesn't work.
First, using a const variable and all sorts of modifiers that I could lookup, it returns an address that seems to be in RAM.
Second, using pointers to functions, I get a value that seems to be ok, but it is the same value regardless of which flash half it's in use; at least as far as I can tell.

I guess there's a remapping of some kind, but I don't have the proper documentation or understanding of the module to figure it out.

Besides, I think I fixed all problems with my OTA upgrade which seems to work fine, so I don't really need this anymore.

Statistics: Posted by sharkx — Mon Feb 01, 2016 2:25 am

Re: How can I REALLY tell which userX.bin is currently executing ?

2016-02-01T00:17:18+08:00

Any another sugestion Expressif_Faye? How to read a constant "real" address from flash?
Someone? This is a good chalenge...

Thx;

Juliano

Statistics: Posted by jkvarela — Mon Feb 01, 2016 12:17 am

Re: How can I REALLY tell which userX.bin is currently executing ?

2016-01-31T15:16:30+08:00

It definitely has NOT to be a regular variable; these get their slot in RAM. Always.
I'll let you know.

Statistics: Posted by sharkx — Sun Jan 31, 2016 3:16 pm

Re: How can I REALLY tell which userX.bin is currently executing ?

2016-01-31T02:52:09+08:00

sharkx;

Maybe the pointer needs to be constant....like this:

const char *p;

dont forget to say to us the result, I am looking for one solution for this too....

Thanks;

Juliano

Statistics: Posted by jkvarela — Sun Jan 31, 2016 2:52 am

Re: How can I REALLY tell which userX.bin is currently executing ?

2016-01-29T11:21:24+08:00

Good point. I'll try.

Statistics: Posted by sharkx — Fri Jan 29, 2016 11:21 am

Re: How can I REALLY tell which userX.bin is currently executing ?

2016-01-29T06:34:33+08:00

Can we try to read address position of a constant in the flash to determine what portion we are using ???

I didn´t test this but can be like this for 512K flash:

uint8_t ICACHE_FLASH_ATTR slotBinCheck(){
const char ref[1] = {"r"};
char *p;
p = &ref;
if ((unsigned long)p > 0x40000){// middle of flash(512K)
return 1;
}
return 0;
}

work? How we can know a address of a constant var in the esp8266??

Statistics: Posted by jkvarela — Fri Jan 29, 2016 6:02 am

Re: How can I REALLY tell which userX.bin is currently executing ?

2016-01-29T06:02:09+08:00

Can we try to read address position of a constant in the flash to determine what portion we are using ???

I didn´t test this but can be like this for 512K flash:

uint8_t ICACHE_FLASH_ATTR slotBinCheck(){
const char ref[1] = {"r"};
char *p;
if ((unsigned long)p > 0x40000){// middle of flash(512K)
return 1;
}
return 0;
}

work?

Statistics: Posted by jkvarela — Fri Jan 29, 2016 6:02 am

Re: How can I REALLY tell which userX.bin is currently executing ?

2016-01-28T16:03:05+08:00

Thanks. I just noticed the boot 1.5 in the 1.5.1 sdk. I'll give it a try.

Statistics: Posted by sharkx — Thu Jan 28, 2016 4:03 pm

Re: How can I REALLY tell which userX.bin is currently executing ?

2016-01-28T14:33:32+08:00

Hi,

1. Please use the latest boot_v1.5.bin. If it tries to run user2.bin when power on, but user2.bin is broken and fails to run, it will jump to run user1.bin automatically.

2. Please always download blank.bin as initialization, if your OTA flag is wrong, maybe due to it.

Thanks for your interest in ESP8266 !

Statistics: Posted by ESP_Faye — Thu Jan 28, 2016 2:33 pm

Re: How can I REALLY tell which userX.bin is currently executing ?

2016-01-25T23:27:19+08:00

Thanks. Actually, that's what I'm afraid of... that the returned flag somehow does no longer match the real execution location.
But I have no clue on how to determine that for sure, so that I either rule out this as the cause for the OTA failure or find a way to fix it.

Here's what happens :
1. I build everything under the eclipse environment;
2. once everything is ok, i use the ubuntu VM to build the .bin files

The build environment is slightly modified :
1. the irom0_text in both LD files is increased to 0x30000 (192 Kb)
2. I removed the user input commands from the gen_build.sh, so that both user1/user2 files get built without other intervention

I flash the boot.bin and both user1/user2.bin to the module; no other flash areas are affected (user and system parameters, etc.). So the module will boot to what it last used.

Next, I try my OTA update. As I said in my previous post, sometimes it works, sometimes not. When it crashes, it is while writing to the address 0x010000 in flash, or immediately after, and the module becomes unusable unless I flash it again over serial.

Now, even if it sounds a bit sci-fi, one of the possible reasons I can think of is this :
1. the module gets updated with both user.bin files
2. it boots to the user2.bin
3. somewhere in the code, it executes an absolute jump (not sure if this exists in this chip, by the way)
4. code continues execution in the user1.bin
5. when it tries to update the user1.bin (according to the flag) it, naturally, crashes.

Of course this can happen because the user.bin files are not correctly built. Hence the question in the subject : how can I tell if this is the case ?

Because the fact that the module becomes unusable after crashing tells me I'm writing to the wrong spot in the flash. If I'm writing to the right user.bin area and it fails, the module should still use the good user.bin and still start.

Any ideas are welcome. Thanks.

Statistics: Posted by sharkx — Mon Jan 25, 2016 11:27 pm

Re: How can I REALLY tell which userX.bin is currently executing ?

2016-01-25T17:44:19+08:00

I had developed OTA program on ESP8266 these days.
I think system_upgrade_userbin_check() does not return the real current app address.
It just return some flag stored in the flash.
So you will program blank.bin to flash to set a initial state:
Boot launch 0x1000 and system_upgrade_userbin_check return 0x0.

Statistics: Posted by grt — Mon Jan 25, 2016 5:44 pm

How can I REALLY tell which userX.bin is currently executing ?

2016-01-22T23:22:28+08:00

Context : module has 512 Kb flash, and I'm trying to develop my own OTA sequence (2*256 Kb), based on the documents on the OTA and memory maps. The reason is that all modules are on a closed network without any PCs.

The problem : sometimes, especially when the new firmware has more changes than the previous version (I do a binary compare; don't care about the code itself), when writing to flash memory (usually at the first flash sector, and more frequently while writing to sector 0001 at 0x001000), the module crashes and it is unrecoverable unless I flash through serial port.

The error I get on the UART1 is a Fatal exception (28), followed by a couple of FE(3) then some FE(4). Sometimes it's a FE(9)... They all somehow seem flash-related (couldn't really find a proper documentation on this).

I'm investigating all possible causes, but so far I'm pretty sure I do write at the proper addresses and that it is the proper content, based on the return value of system_upgrade_userbin_check(). Besides, even if write garbage to the proper address space, it should crash on reset, NOT while writing to flash.

So one of the possibilities that I'm looking at is that I'm writing to the wrong address space; and by wrong I do not mean wrong according to the return value of system_upgrade_userbin_check(), but the REAL currently executing code.

Can anyone help find the answer to the question : how can I tell where my code is REALLY execution from ?
Something like getting the value of the IP register (either directly or through a CALL/POP trick like in the good ol' days)
I know it sounds strange, but I need this just to rule out this scenario.

Thanks in advance.

Statistics: Posted by sharkx — Fri Jan 22, 2016 11:22 pm