ESP8266 Community Forum

- Fri Sep 10, 2021 2:46 am #92296 I am also worried about the max flash frequency (you may be talking about this). Each flash chip type has a maximum clock frequency it can be driven at. Most are quite a bit higher than the SDK code sets it up for (according to esptool that's either 40, 26, 20 or 80 Mhz), I believe iet's 40 Mhz by default but most chips (but not all...) will also run at 80 Mhz. If your change to the PLL also influences the flash clock, it would go up by more than 100%, the flash clock would raise to above 80 Mhz...

So I think the safest approach is to only raise the clock to about 200% (320 Mhz).

I am also very curious which peripherals still work at that frequency and if we even get wifi working, it would be great (but I don't count on it).

If you have a "simple" procedure for me, I could test that too. I'd like to test:
- can we raise the clock speed and then also lower it again to "normal" settings
- what will still work at the raised speed
- if wifi doesn't work, can be make a procedure where wifi is temporarily shut down (there is SDK code for that), clock raised, do the work, clock reset and then enable wifi again. Maybe it even works without temporarily shutting down wifi.
- just as the flash clock is probably influenced by the PLL clock (SPI peripheral), the HSPI peripherical will probably too. I may keep working, but we'd need to adjust the dividers to keep the proper frequency.

- Fri Sep 10, 2021 2:54 am #92297 I had this interesting idea to go see where this function rom_rfpll_set_freq was used, so we checkout how they're calling the function. But apperently none of the rom code calls it . That would mean we'd have to disassemble the SDK libs...

- Fri Sep 10, 2021 3:15 am #92299 Checked, none of the SDK code calls this function. In the SDK libs there are various functions that have names like this, so I guess, just like the CacheEnable functions, there have been created newer, "improved" versions in the SDK libs.

So we're still waiting for someone who has the time, interest and knowledge to disassemble not just the ROM code, but the actual code path (including libs) that is taken from boot until image code handover. It may very well be that 80-90% of the ROM code isn't used there.

- Fri Sep 10, 2021 12:03 pm #92305

I am also worried about the max flash frequency (you may be talking about this). Each flash chip type has a maximum clock frequency it can be driven at. Most are quite a bit higher than the SDK code sets it up for (according to esptool that's either 40, 26, 20 or 80 Mhz), I believe iet's 40 Mhz by default but most chips (but not all...) will also run at 80 Mhz. If your change to the PLL also influences the flash clock, it would go up by more than 100%, the flash clock would raise to above 80 Mhz...

So I think the safest approach is to only raise the clock to about 200% (320 Mhz).

I am also very curious which peripherals still work at that frequency and if we even get wifi working, it would be great (but I don't count on it).

If you have a "simple" procedure for me, I could test that too. I'd like to test:
- can we raise the clock speed and then also lower it again to "normal" settings
- what will still work at the raised speed
- if wifi doesn't work, can be make a procedure where wifi is temporarily shut down (there is SDK code for that), clock raised, do the work, clock reset and then enable wifi again. Maybe it even works without temporarily shutting down wifi.
- just as the flash clock is probably influenced by the PLL clock (SPI peripheral), the HSPI peripherical will probably too. I may keep working, but we'd need to adjust the dividers to keep the proper frequency.

To test things out, you can clone my version of nosdk8266 project (https://github.com/0z4/nosdk8266) and see src/nosdk8266.c, include/nosdk8266.h and main.c there are the important parts. in the Makefile you need set the path of Xtensa GCC and esptool.py. then

Code: Select allmake clean all burn

And the code will be loaded into the ESP