Running at 160MHz

[dkinzer]

Various sources indicate that the CPU frequency can be changed from 80MHz to 160MHz by setting bit 0 at 0x3ff00014 with the caveat that os_update_cpu_frequency() must be called to indicate the operating frequency (in MHz). I have tried using this sequence in my user_init(), my post_init() and in the task itself. In all cases, the processor appears to continue to run at 80MHz as evidenced by the resulting UART baud rate and the speed of toggling an output pin, both being half of what they should be. The test app was linked with the v1.2.0 SDK which, by the way, no longer contains the prototype for os_update_cpu_frequency().

Has anyone else been able to get this to work reliably?

[blubb]

Try

system_update_cpu_freq(160);

[dkinzer]

system_update_cpu_freq(160);

Thanks. There is a prototype in the v1.2.0 SDK for that function but still no joy. After setting the frequency to 160MHz a UART divisor of 694 yields 115200 baud rather than 230400 as it should thus indicating the the CPU is still running at 80MHz.

[ESP_Faye]

Hi，

CPU changes to 160MHz would not have effect on the clock for UART.

So UART baudrate will not change.

Thanks for your interest in Espressif Systems and ESP8266 !

[eriksl]

The defines in the include files suggest the cup clock is directly as uart clock (which then is divided then of course), so it looks like either one is wrong.

[dkinzer]

The defines in the include files suggest the cup clock is directly as uart clock.

I agree that the defines in the include file are misleading. I've done some additional testing and this is what I've found:

o It appears not to be necessary to use REG_SET_BIT() or REG_CLR_BIT() to change the speed. Simply calling system_update_cpu_freq() with a parameter of 80 or 160 effects the desired speed. Alternately, one can set/clear the register bit instead of calling system_update_cpu_freq(). In other words, using either alone appears to have the same effect and using both together does not appear to have any additional effect.

o Specifying a CPU speed of 160 does, in fact, change the execution speed to 160MHz. I confirmed this using an app that toggled an output several times and observed with a logic analyzer that the period was about one-half of that measured when operating at 80MHz.

o The UART baud rate is not affected by the CPU speed setting. A given divisor produces the same baud rate with both speed settings.

o The timers of the RTC are not affected by the CPU speed setting. A given timer divisor produces the same rate of change of the RTC timer's COUNT register with both speed settings.

[eriksl]

That's interesting information, thanks for finding that out.

It's also a mode of operation that's very easy to use that way, with little side-effects, that's nice.

All of this should have been in the documention of the relevant api function of course

[dkinzer]

Confirming my observations, the v1.3.0 SDK documentation has this note in the description of system_update_cpu_freq():

Note:
System bus frequency is 80MHz, will not be affected by CPU frequency. The
frequency of UART, SPI, or other peripheral devices, are divided from system
bus frequency, so they will not be affected by CPU frequency either.

[ESP_Faye]

Hi,

So sorry that UART clock confused you~ we will revise it in next version of SDK.

Thanks for your interest in ESP8266 !

[skywave]

Are there any drawbacks of using the CPU at 160Mhz instead?