ESP8266 Community Forum

- Thu Sep 09, 2021 10:10 am #92278

40007975: 05cd mov.n a12, a5; move a5 to a12, I am not sure what a5 is at this moment, maybe also a way to save it
40007977: fff7e1 l32r a14, 40007954 <pllat_00000040>; copy the 32 bit value at 40007954 to a14, this is a location just before the code of this function, this is value 400000
4000797a: 0d0c movi.n a13, 0; set a13 to 0
4000797c: 110260 slli a0, a2, 10; take register a2 (frame pointer?), shift it by 10 and put it in a0 (scratch?)
4000797f: 040a add.n a0, a4, a0; add a4 to a0 (what is a4?)
40007981: 1120e0 slli a2, a0, 2; take register a0, shift it by 2 and store it (back) to a2
40007984: 069605 call0 4000e2e8 <__floatunsidf>; convert unsigned long int in a2 to a double

- Thu Sep 09, 2021 11:25 am #92279

Code: Select all40007968:   e0c112     addi   a1, a1, -32
4000796b:   0139         s32i.n   a3, a1, 0
4000796d:   1109         s32i.n   a0, a1, 4
4000796f:   31d9         s32i.n   a13, a1, 12
40007971:   21c9         s32i.n   a12, a1, 8
40007973:   41e9         s32i.n   a14, a1, 16
40007975:   05cd         mov.n   a12, a5
40007977:   fff7e1       l32r           a14, 40007954 <pllat_00000040>
4000797a:   0d0c         movi.n   a13, 0
4000797c:   110260    slli           a0, a2, 10
4000797f:   040a         add.n   a0, a4, a0
40007981:   1120e0    slli           a2, a0, 2
40007984:   069605    call0   4000e2e8 <__floatunsidf>
40007987:   fff451       l32r           a5, 40007958 <pllat_0840c000>; move #080000 to a5
4000798a:   040c         movi.n   a4, 0; move #0 to a4
4000798c:   052045    call0   4000cb94 <__divdf3>; call divdf3, double a / double b; a2+a3 = double a, a4+a5 = double b
4000798f:   053cc5    call0   4000cd5c <__truncdfsf2>; truncate from double to float (8 -> 4 bytes)
40007992:   054685    call0   4000cdfc <__extendsfdf2>; again extend to double (4 -> 8 bytes) # interesting...
40007995:   0148         l32i.n   a4, a1, 0; load 0(a1) in a4
40007997:   062416    beqz   a4, 400079fd <rom_rfpll_set_freq+0x95>; if a4 == 0 goto line 12331
4000799a:   fff051       l32r           a5, 4000795c <pllat_000000da>; move #da0000 to a5
4000799d:   00a042    movi   a4, 0; move #0 to a4; this is a double constant together with a5
400079a0:   051f05     call0   4000cb94 <__divdf3>; divide a2_a3 by a4_a5
400079a3:   0d4d         mov.n   a4, a13; move a13 to a4, not sure what's in a13 at this point
400079a5:   205ee0    or           a5, a14, a14; move a14 to a5 (xtensa does it this way...)
400079a8:   04b8c5    call0   4000c538 <__adddf3>; add double a13_14 to double a2_a3
400079ab:   053b05    call0   4000cd5c <__truncdfsf2>; truncate to float
400079ae:   02ed         mov.n   a14, a2; move a14 to a2 (what's in a14?)
400079b0:   ffecd1      l32r         a13, 40007960 <pllat_43004000>; move #800000 to a13
400079b3:   0e2d         mov.n   a2, a14; move a14 to a2; this is weird, it looks like a2 is saved for a function call that is optimised away
400079b5:   04b0c5    call0   4000c4c4 <__fixunssfsi>; convert float to unsigned int
400079b8:   004c22     s8i           a2, a12, 0; store 8 bits from a2 to 0(a12)
400079bb:   742020     extui   a2, a2, 0, 8; mask bits 0-8 in a2
400079be:   068ec5    call0   4000e2ac <__floatsisf>; convert integer to float
400079c1:   023d         mov.n   a3, a2; move a2 to a3
400079c3:   0e2d         mov.n   a2, a14; move a14 to a2
400079c5:   048a05    call0   4000c268 <__subsf3>; subtract double a2_a3 from double a4_a5
400079c8:   0d3d         mov.n   a3, a13; move a13 to a3
400079ca:   04a105    call0   4000c3dc <__mulsf3>; multiply
400079cd:   02ed         mov.n   a14, a2; move a2 to a14;
400079cf:   04af45     call0   4000c4c4 <__fixunssfsi>; convert float to unsigned int
400079d2:   014c22    s8i           a2, a12, 1; store 8 bits from a2 to 1(a12)
400079d5:   742020    extui   a2, a2, 0, 8; mask bits 0-8 in a2
400079d8:   068d05    call0   4000e2ac <__floatsisf>; convert integer to float
400079db:   023d         mov.n   a3, a2; move a2 to a3
400079dd:   0e2d         mov.n   a2, a14; move a14 to a2
400079df:   048885    call0   4000c268 <__subsf3>; subtract floats
400079e2:   0d3d         mov.n   a3, a13; move a13 to a3
400079e4:   049f45     call0   4000c3dc <__mulsf3>; multiply float
400079e7:   04adc5    call0   4000c4c4 <__fixunssfsi>; convert float to unsigned int
400079ea:   1108         l32i.n   a0, a1, 4; load 4(a1) in a0, probably function epilog, restore values
400079ec:   31d8         l32i.n   a13, a1, 12; load 12(a1) in a13
400079ee:   024c22    s8i           a2, a12, 2; store 8 bits from a2 in 2(a12)
400079f1:   41e8         l32i.n   a14, a1, 16; load 16(a1) in a14
400079f3:   21c8         l32i.n   a12, a1, 8; load 8(a1) in a12
400079f5:   20c112    addi        a1, a1, 32; restore stack pointer
400079f8:   f00d         ret.n       ; return


Now this is where the conditional jump is to at the start of the function:

Code: Select all400079fd:   ffd951      l32r         a5, 40007964 <pllat_00e44080>
40007a00:   00a042    movi      a4, 0
40007a03:   051905    call0      4000cb94 <__divdf3>
40007a06:   204dd0    or          a4, a13, a13
40007a09:   205ee0    or          a5, a14, a14
40007a0c:   04b285    call0      4000c538 <__adddf3>
40007a0f:   0534c5    call0      4000cd5c <__truncdfsf2>
40007a12:   02ed         mov.n    a14, a2
40007a14:   ffe606      j             400079b0 <rom_rfpll_set_freq+0x48>; jump back to line 12301, 0x400079b0


My preliminary conclusion is that this function does nothing whatsoever with hardware. It's merely a function that seems to calculate values. I will have another look to check. Maybe you should supply the I/O address as a parameter, not sure, but it's not in the code.

- Thu Sep 09, 2021 11:32 am #92280 Something is written to the adress in a5, which transferred to a12 later. I think that is the only point where something is written to memory/IO other than to stack.

It looks like:

a2_a3 double argument 1
a4 int argument 1
a5 pointer/int argument

- Thu Sep 09, 2021 11:48 am #92281

I am very curious of your findings.

Do you do anything with the "cpu clock doubler" (i.e. turn it off or on explicitly)? I'd rather have a CPU running at a "high" frequency and the APB at half of it (like it normally does), because then there is more chance that all peripherals will continue to work.

The CacheReadEnable (-Disable) functions have to do with mapping flash memory to IRAM. I am not sure how your knowledge is at this point, forgive me if you already know: there is in total 64 kb IRAM in the ESP8266. 32 kb is used for "iram" code i.e. functions that are not specifically mentioned as to not cache in IRAM. The other 32 kb is used for caching flash memory as the processor cannot execute instructions directly from flash. The CacheReadEnable functions (or CacheReadEnable2 versions) set up this caching. They can "mirror" at most 1 Mbyte of flash memory and you can choose which one, out of four (@ 0 Mb, @ 1 Mb, @ 2 Mb, @ 3 Mb).

I think your code runs in IRAM (I don't know how you build it to an image?), so it shouldn't depend on the flash cache. I don't know why the nonosdsk does something with it anyway?

I use the function

Code: Select all$(ESPTOOL) elf2image $(TARGET_OUT) -o $(TARGET_OUT)-0x00000.bin

the same as in nosdk8266 but for the last esptool.py.

Yes, i do set the overclock bit, so i have a PLL of ~195 MHz and the CPU of ~390 MHz.
Yesterday i made a lot of experiments, but after disable I2S (i find that I2S at such that speed cause troubles) and disable the cache, my code work for a time and then it start generating errors. Maybe was soemthing that i change, but im implemmenting all things again in a new copy of my nosdk8266 fork to merge all tested.

i found this combination: 189/0x00/0x88 (UART divider at 189, this means PLL at 189 MHz, CPU reg 0x00, Charles wrote that this put the CPU at arround 190 MHz and 0x88 on the PLL reg, this put the PLL at arround ~185 MHz)

So, in an hour or so i will start removing all I2S/Cache code and see if it still stable at 346 MHz, if all works for an hour, i will inseert the 390 MHz registers and do a test over all the night.

I remember that yesterday, i ended up with some FLASH reading errors, some printf errors and some error in main (all from disrom.S) so i guess that the ESP8266 start failing at this such speed. we need check rfpll_set_freq, of find in the ROM where is the code that sets the PLL/CPU divider and change it.