ESP8266 Community Forum

- Tue Sep 07, 2021 1:07 pm #92233

Already impressive!

I hope you can, at some point, work out what the baud rate actually is for a certain pair of clock settings.

Maybe you can use autobaud'ing. I have a software oscilloscope that can work out the actual baud rate from some bytes of input.

I use the baudrate errors to map the frequencys! The second foor loop sends the same message on every possible PLL speed from 0 to 200 MHz, usually i receive the same message on unnassembled caracters on the terminal (becouse the unsuported PLL freq) but when i see the correctly, that mean that the PLL is working on a valid frequency! I used this formula https://github.com/cnlohr/nosdk8266/blob/master/src/nosdk8266.c#L123 PERIPH_FREQ is equal to the core clock / 2 ( we divide by 2 if the desired core freq is above 160 MHz)

- Tue Sep 07, 2021 2:21 pm #92235 Great work, I am impressed and very curious how it will go from here.

From other microcontrollers I know that not all combinations of PLL and clock dividers give a valid or sensible clock frequency. Also sometimes all values are not always logical (e.g. after 1=1/2, 2=1/4, 3=1/8 etc, the pattern may change at some point). Also probably the same piece of hardware controls both the "PLL" and more than one clock divider, as the APB runs at a different speed. It would be great if we could find a combination where the CPU runs at a higher speed, but the APB still runs at 80 Mhz, that would probably mean WiFi will still be working.

- Tue Sep 07, 2021 2:39 pm #92236 Check this
I just finish it, replace

Code: Select allrom_i2c_writeReg(103, 4, 1, ...);

With the desired value! the highest that i found was 184 MHz on values 0x81..0x8F and 0x91...0x9F.
This mean that we can push the main clock to 368 MHz, thats a 22 MHz improve over last stable frequencie founded by Charles. Tomorrow i will try map the core clock values, but if we cant push the PLL further, we are stuck. the last thing that i have in my mine can be try use

Code: Select allrom_rfpll_set_freq

but i dont know much about asm and i dont understeand disrom.S

- Wed Sep 08, 2021 10:18 am #92240 This is just by calling rom_i2c_writeReg I guess. So I assume you use the system API function (or direct hardware access) for setting 160 MHz clock to double the PLL CPU clock? Or something else?

As some ranges yield the same frequency, it looks like only some bits are used for PLL/clock divider. I think we should work out which bits are significant and only use these, the other bits may have another function and may be messing up other operation, who knows...

I think 368 MHz already is very good, as the rumours are that the CPU can run up to ~400 Mhz.

I am quit experienced in assembly programming, it's just that it's Z80 and 68000 assembly language . But I do have a document that describes xtensa instructions, so we should be able to figure out what it does. I already read the rom code does some obfuscation by adding and subtracting some "magical" values, bah.

In the end I'd like for us to actually know what I/O addresses are used and them access them directly, without obfuscating rom code. I believe some already had found out some of this.