0.66 clock scaling after reset

[mattd5574]

I'm running into some interesting power-on behavior with a project based on the espea32 board. When I plug USB port on the device into certain Windows machines, it toggles the serial control lines and causes a reboot (I assume some probing behavior). This isn't a surprise, but the problem is that after the reboot, the clock speeds seem to be incorrect.

The obvious symptom was that the UARTs started producing garbage. On the scope, I see that the waveforms are being driven by a clock that's 66% of the normal clock, producing an invalid baud rate. Putting a GPIO in a tight on/off loop to produce a square wave gets the same result: The square wave slows down as though the clock driving it has been multiplied by 0.66.

Based on the clock diagrams in the TRM and the fact that register reads indicate that pll_clk is driving those subsystems, my tentative conclusion is that pll_clk is locking at a different clock speed after the reboot.

A few more observations:

1) Changing the main xtal frequency setting from autodetect to 40MHz doesn't change the behavior.

2) Simply wiggling the serial control lines with a python script from a Linux machine causes a normal reset and the clocks come up as expected. There seems to be something order/state/timing sensitive in this behavior, but I can't control what a user's serial port may do, so I have to recover somehow.

3) If I rerun make menuconfig and select 160MHz for the CPU clock speed, the system works properly both before and after the reset.

There's nothing timing critical in my application, so (3) is a potential workaround, but I'd like to get to the bottom of this. I'm also confused by the fact that the TRM (as of November 10, 2017) makes no reference to a 240MHz CPU clock speed. It only discusses 160MHz (320MHz pll_clk/2) while the IDF code and other docs all indicate that 240MHz is the max (presumably a 480MHz pll_clk/2, if the TRM's clock division table is correct). This factor would neatly explain the 2/3 division I'm seeing, but I'm not clear on what's causing it.

[WiFive]

Can you say which branch/commit of esp-idf you are using

[mattd5574]

Sorry for the long delay. I didn't see the post appear and thought it was eaten. I'm going to rerun my tests this week with the latest IDF and see if I can reproduce it. I'll report my observations.

Thanks!