eriksl wrote: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
Advanced Users can post their questions and comments here for the not so Newbie crowd.
40007968: 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:
400079fd: 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.
It looks like:
a2_a3 double argument 1
a4 int argument 1
a5 pointer/int argument
eriksl wrote: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
$(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.