0.66 clock scaling after reset

Posts: 1
Joined: Tue Nov 14, 2017 7:05 pm

0.66 clock scaling after reset

Postby mattd5574 » Tue Nov 14, 2017 7:07 pm

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.

Posts: 1205
Joined: Tue Dec 01, 2015 7:35 am

Re: 0.66 clock scaling after reset

Postby WiFive » Wed Nov 15, 2017 3:22 am

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

Who is online

Users browsing this forum: Google [Bot], WiFive and 10 guests