Discuss here different C compiler set ups, and compiling executables for the ESP8266
User avatar
By Pato
#78075 So here is the mapfile in attachement (thanks for your involvement). of the example above (what are you looking for ?).

The exact message I have is:
Code: Select allFatal exception (0):
epc1=0x40210c54, epc2=0x00000000, epc3=0x00000000, excvaddr=0x00000000, depc=0x00000000


However, note that with my other softwre, the epc1 was always around 0x401000**, at an address that did not appear in the disasembled file. But in this sample code, the address 0x40210c54 is found.
Here is what the dissasembled looks like around that address (I enlighted it in bold), in case it help:

Code: Select all...
40210bbc <user_rf_cal_sector_set>:
40210bbc:   e0c112           addi   a1, a1, -32
40210bbf:   7109         s32i.n   a0, a1, 28
40210bc1:   61f9         s32i.n   a15, a1, 24
40210bc3:   20f110           or   a15, a1, a1
40210bc6:   fffa21           l32r   a2, 40210bb0 <wpa_sm_disassociate+0x4>
40210bc9:   c46001           l32r   a0, 40201d4c <ieee80211_chan2ieee+0x44>
40210bcc:   0000c0           callx0   a0
40210bcf:   005005           call0   402110d0 <system_get_flash_size_map>
40210bd2:   1f29         s32i.n   a2, a15, 4
40210bd4:   020c         movi.n   a2, 0
40210bd6:   0f29         s32i.n   a2, a15, 0
40210bd8:   1f28         l32i.n   a2, a15, 4
40210bda:   4e92f6           bgeui   a2, 10, 40210c2c <user_rf_cal_sector_set+0x70>
40210bdd:   1f28         l32i.n   a2, a15, 4
40210bdf:   1132e0           slli   a3, a2, 2
40210be2:   fff421           l32r   a2, 40210bb4 <wpa_sm_disassociate+0x8>
40210be5:   232a         add.n   a2, a3, a2
40210be7:   0228         l32i.n   a2, a2, 0
40210be9:   0002a0           jx   a2
40210bec:   7ba022           movi   a2, 123
40210bef:   0f29         s32i.n   a2, a15, 0
40210bf1:   000f46           j   40210c32 <user_rf_cal_sector_set+0x76>
40210bf4:   fba022           movi   a2, 251
40210bf7:   0f29         s32i.n   a2, a15, 0
40210bf9:   000d46           j   40210c32 <user_rf_cal_sector_set+0x76>
40210bfc:   fba122           movi   a2, 0x1fb
40210bff:   0f29         s32i.n   a2, a15, 0
40210c01:   000b46           j   40210c32 <user_rf_cal_sector_set+0x76>
40210c04:   fba122           movi   a2, 0x1fb
40210c07:   0f29         s32i.n   a2, a15, 0
40210c09:   000946           j   40210c32 <user_rf_cal_sector_set+0x76>
40210c0c:   fba322           movi   a2, 0x3fb
40210c0f:   0f29         s32i.n   a2, a15, 0
40210c11:   000746           j   40210c32 <user_rf_cal_sector_set+0x76>
40210c14:   fba322           movi   a2, 0x3fb
40210c17:   0f29         s32i.n   a2, a15, 0
40210c19:   000546           j   40210c32 <user_rf_cal_sector_set+0x76>
40210c1c:   fba722           movi   a2, 0x7fb
40210c1f:   0f29         s32i.n   a2, a15, 0
40210c21:   000346           j   40210c32 <user_rf_cal_sector_set+0x76>
40210c24:   ffe521           l32r   a2, 40210bb8 <wpa_sm_disassociate+0xc>
40210c27:   0f29         s32i.n   a2, a15, 0
40210c29:   000146           j   40210c32 <user_rf_cal_sector_set+0x76>
40210c2c:   020c         movi.n   a2, 0
40210c2e:   0f29         s32i.n   a2, a15, 0
40210c30:   f03d         nop.n
40210c32:   0f28         l32i.n   a2, a15, 0
40210c34:   0f1d         mov.n   a1, a15
40210c36:   7108         l32i.n   a0, a1, 28
40210c38:   61f8         l32i.n   a15, a1, 24
40210c3a:   20c112           addi   a1, a1, 32
40210c3d:   f00d         ret.n
40210c3f:   800000           add   a0, a0, a0
40210c42:   fe             .byte 0xfe
40210c43:   3f             .byte 0x3f
[b]
40210c44 <system_set_os_print>:[/b]
[b]40210c44[/b]:   ffff31           l32r   a3, 40210c40 <user_rf_cal_sector_set+0x84>
40210c47:   140c         movi.n   a4, 1
40210c49:   932420           movnez   a2, a4, a2
40210c4c:   004322           s8i   a2, a3, 0
40210c4f:   f00d         ret.n
40210c51:   000000           ill

40210c54 <system_get_os_print>:
40210c54:   fffb21           l32r   a2, 40210c40 <user_rf_cal_sector_set+0x84>
40210c57:   000222           l8ui   a2, a2, 0
40210c5a:   f00d         ret.n
40210c5c:   fe86e4           excw
40210c5f:   3f             .byte 0x3f
40210c60:   210d30           srai   a0, a3, 13
40210c63:   fff040           excw
40210c66:   9c4022           s8i   a2, a0, 156
40210c69:   3ffe87           bbsi   a14, 24, 40210cac <system_get_os_print+0x58>
40210c6c:   f0c112           addi   a1, a1, -16
40210c6f:   0261c2           s32i   a12, a1, 8
40210c72:   0129         s32i.n   a2, a1, 0
40210c74:   1109         s32i.n   a0, a1, 4
...
You do not have the required permissions to view the files attached to this post.
User avatar
By jcmvbkbc
#78090
Pato wrote:
Code: Select allFatal exception (0):
epc1=0x40210c54, epc2=0x00000000, epc3=0x00000000, excvaddr=0x00000000, depc=0x00000000


However, note that with my other softwre, the epc1 was always around 0x401000**, at an address that did not appear in the disasembled file. But in this sample code, the address 0x40210c54 is found.

Exception cause 0 (illegal instruction) together with the epc1 address pointing to FLASH means that there's code that tries to call function from FLASH when it is not mapped. --gc-sections would not affect existence of that code path, but it may alter FLASH caching, making it work or not work, depending on cache contents.

That is, there's definitely a bug that such code path exists, and the fix is to avoid calling function from FLASH when it is not mapped.

Stack backtrace at the moment of crash is the most direct way to debug it.
If there's no way to collect backtrace you can look at callers of the system_get_os_print (a list of callers may be obtained from linker with --cref option).
User avatar
By Pato
#78167 Hey jcmvbkbc !

I updated the mapfile with the cross reference table.
(what info are you looking for, so that I can help ?)

NB: As said, before I wrote this minimal sample code, the exception pointer was around 0x401000xx, pointing to nothing
You do not have the required permissions to view the files attached to this post.