Skip to content

UART initialisation from cold boot sets crystal clock wrong #10388

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
1 task done
emilfihlman opened this issue Sep 29, 2024 · 24 comments
Closed
1 task done

UART initialisation from cold boot sets crystal clock wrong #10388

emilfihlman opened this issue Sep 29, 2024 · 24 comments
Labels
Status: Awaiting triage Issue is waiting for triage

Comments

@emilfihlman
Copy link

emilfihlman commented Sep 29, 2024

Board

Sparkfun Thing Plus

Device Description

Just the breakout board without nothing (except oscilloscope probes on 16, 17 and gnd) on it and connected to the computer via usb

Hardware Configuration

Just the breakout board without nothing (except oscilloscope probes on 16, 17 and gnd) on it and connected to the computer via usb

Version

3.0.5

IDE Name

arduino-ide_nightly-20240928_Linux_64bit

Operating System

Debian 12.7 Linux hostname 6.1.0-25-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.1.106-3 (2024-08-26) x86_64 GNU/Linux

Flash frequency

80 MHz

PSRAM enabled

no

Upload speed

921600

Description

When connected to computer from no power, device initially starts with 3u period and then immediately switches to 4.5u

On reset button press (ie warm reboot), device stays at 3u period.

When connected to just a power plug from no power, device also stays at 3u period.

RMT is probably just a red herring here, it allows us to easily see a stable frequency at least.

Sketch

#define PIN 16

void setup()
{
	rmt_data_t rawData[]={{.duration0=1, .level0=0, .duration1=1, .level1=1}};
	pinMode(PIN, OUTPUT);
	rmtInit(PIN, RMT_TX_MODE, RMT_MEM_NUM_BLOCKS_1, 1000000);
	rmtWriteLooping(PIN, rawData, RMT_SYMBOLS_OF(rawData));
}

void loop(){}

Debug Message

No messages

Other Steps to Reproduce

Tried multiple of the same device, unopened.

https://youtu.be/8VOk3C6BlFE video of issue

I have checked existing issues, online documentation and the Troubleshooting Guide

  • I confirm I have checked existing issues, online documentation and Troubleshooting guide.
@emilfihlman
Copy link
Author

emilfihlman commented Sep 29, 2024

And just to make it clear: I have rebooted my computer and reinstalled the esp32 package.

@TD-er
Copy link
Contributor

TD-er commented Sep 29, 2024

What crystal frequency does your board use?
26 or 40 MHz?

@emilfihlman
Copy link
Author

What crystal frequency does your board use? 26 or 40 MHz?

According to the datasheet (ESP32-WROOM-32D) it's supposed to be 40 MHz, but indeed this has some same characteristics as that bug that's supposedly fixed.

Even if it was 26 MHz, there's still another bug because it doesn't stay at one frequency.

@emilfihlman
Copy link
Author

emilfihlman commented Sep 29, 2024

You also asked about PSRAM and pins 16 and 17.

No PSRAM and also I was under the impression that 16 and 17 were clean https://randomnerdtutorials.com/esp32-pinout-reference-gpios/

@emilfihlman
Copy link
Author

And I should say I'm getting data at 74880 (well that works so it's close enough) when setting 115200 on Serial if using Serial.

@TD-er
Copy link
Contributor

TD-er commented Sep 29, 2024

You also asked about PSRAM and pins 16 and 17.

No PSRAM and also I was under the impression that 16 and 17 were clean https://randomnerdtutorials.com/esp32-pinout-reference-gpios/

I did ask about PSRAM as it is my Pavlov reaction when I see ESP32-classic and GPIO-16/-17 being mentioned. (have been bitten by it myself several times)
But then I noticed you had ticked the "no PSRAM" in the template, so I removed it from my post.

@TD-er
Copy link
Contributor

TD-er commented Sep 29, 2024

And I should say I'm getting data at 74880 (well that works so it's close enough) when setting 115200 on Serial if using Serial.

Yep, 115200 ÷ 40 × 26 = 74880, which supports my hypothesis your board may be using a 26 MHz crystal.

@emilfihlman
Copy link
Author

And I should say I'm getting data at 74880 (well that works so it's close enough) when setting 115200 on Serial if using Serial.

Yep, 115200 ÷ 40 × 26 = 74880, which supports my hypothesis your board may be using a 26 MHz crystal.

I mean yeah, but I can't for the life of me figure out how to definitely tell the software that it's 26 MHz. I tried putting that everywhere I could for many hours.

And in any case there are bloody 2 frequencies, both 74880 and 115200 depending on how it is rebooted AND how it is connected :D

I really don't know how I can run into issues like these T.T

@emilfihlman
Copy link
Author

Like, I tried applying the fix from the mentioned issues, the only difference being adding the one define to the pins file in variants since everything else was already there.

But it still has the same behaviour.

@me-no-dev
Copy link
Member

just to clarify: the only case where it switches to 4.5u is when you connect it to your computer? every other case results to 3u?

@emilfihlman
Copy link
Author

emilfihlman commented Oct 1, 2024

just to clarify: the only case where it switches to 4.5u is when you connect it to your computer? every other case results to 3u?

As far as I can tell, yeah, that's the case.
But like I didn't test mega extensively since it was already like 9 in the morning after a whole evening and night of debugging.

@emilfihlman
Copy link
Author

You can see in the video my setup in case you didn't already watch it, it shows the extent and limits of my test.

@ramack
Copy link

ramack commented Oct 11, 2024

I also have a Sparkfun ESP32 Thring Plus uFL and seemingly have the same issue, but for me not even the workaround works. With the wallplug connector instead of USB powered Wifi connection works (which indicates the correct clock settings) while with USB connected the Serial console is on 74880 instead of 115200 Baud and no Wifi connection is established.

@emilfihlman
Copy link
Author

@ramack at the same time I'm glad it wasn't just me but also it sucks that it's an actual issue.

Thank you for also reporting this, maybe @me-no-dev @TD-er can use this as a confirmation of the issue and try to find a fix or have someone with more knowledge provide a fix.

@emilfihlman
Copy link
Author

@me-no-dev @TD-er any news?

@emilfihlman
Copy link
Author

@me-no-dev @TD-er anything yet?

@TD-er
Copy link
Contributor

TD-er commented Nov 11, 2024

I don't have any update, as I am not involved in this.
I am just another user trying to help others where I can.

Also I don't have any of those boards which behave like yours.

@emilfihlman
Copy link
Author

Ah sorry about that! I won't highlight you again haha

Thank you for trying to help : )

@emilfihlman
Copy link
Author

Would it help if I provide remote (both terminal and gui work) access to the device for testing @me-no-dev ?

@me-no-dev
Copy link
Member

I just need some spare time to figure out how to reproduce. AMF this should not happen, as in both boot types, the chip goes through the same code.

@Jason2866
Copy link
Collaborator

closing since outdated feel free to ask to reopen if the issue still exists with actual Arduino core

@emilfihlman
Copy link
Author

@Jason2866 still persists as per #9837 (comment)

@Jason2866
Copy link
Collaborator

reopened #9837 since same and there is an example code.

@emilfihlman
Copy link
Author

reopened #9837 since same and there is an example code.

Just to let you know, this one has had example code from the get go...

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Status: Awaiting triage Issue is waiting for triage
Projects
None yet
Development

No branches or pull requests

5 participants