Skip to content
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

ESP.getChipModel() returns incorrect chip name: "ESP32-D0WD" instead of "ESP32-D0WD-V3" #10238

Closed
1 task done
mscott370 opened this issue Aug 25, 2024 · 6 comments · Fixed by #10243
Closed
1 task done
Labels
3.0 migration issue relates to migration from 2.X to 3.X version Status: In Progress Issue is in progress
Milestone

Comments

@mscott370
Copy link

Board

ESP32-DEVKITC-VIE

Device Description

ESP32 WROVER-IE chip on DevKitC V4 board.

  • Using Arduino IDE board definition "ESP32 Wrover Kit (all versions)"

Hardware Configuration

No, only serial USB connection to Arduino IDE host.

Version

v3.0.4

IDE Name

Arduino IDE v2.3.2

Operating System

Both on Windows 11 and on Ubuntu Linux 24.04

Flash frequency

80Mhz

PSRAM enabled

yes

Upload speed

115200

Description

When uploading code to ESP32, ESPtool.py identifies the chip model correctly as ESP32-D0WD-V3, but ESP.getChipModel() returns a value of "ESP32-D0WD" which indicates chip model V1 not V3.
This error seems to be caused by the following code in ESP.cpp
270 case EFUSE_RD_CHIP_VER_PKG_ESP32D0WDQ5:
271 if (getChipRevision() == 3) {
272 return "ESP32-D0WD-V3";
273 } else {
274 return "ESP32-D0WD";
275 }
The above code was valid in IDF V4.4 when the value returned by getChipRevision() was simply the major wafer revision number (3) (uint8_t). This value was changed in IDF v5 to uint16_t, consisting of [major version]*100 + [minor version]. In my case, the value returned is 303, so as 303 is not == 3, we fall through into the else clause and return Chip Model = "ESP32-D0WD".

A quick+dirty change of the if-statement to "if (getChipRevision() /100 == 3) {" produces the correct result, so it looks like this is an IDF v5 / Arduino-ESP32 V3 migration issue.

Sketch

String chip_name =  ESP.getChipModel();
  Serial.println("Chip Model = " + chip_name);   // Display initial result from GetChipModel()
  esp_chip_info(&chipinfo);                      // Fill chipinfo structure
  bool rev3 = (chipinfo.revision/100) == 3;
  bool single_core = chipinfo.cores == 1;
  if (chip_name == "ESP32-D0WD" && rev3)  {      // If result invalid (Rev3 not valid with D0WD-V1),    
     chip_name += "-V3";                         // modify chip name
     Serial.println("Real Chip Model = " + chip_name);
     }

Debug Message

None

Other Steps to Reproduce

No

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

  • I confirm I have checked existing issues, online documentation and Troubleshooting guide.
@mscott370 mscott370 added the Status: Awaiting triage Issue is waiting for triage label Aug 25, 2024
@Jason2866 Jason2866 added 3.0 migration issue relates to migration from 2.X to 3.X version and removed Status: Awaiting triage Issue is waiting for triage labels Aug 25, 2024
@me-no-dev
Copy link
Member

I would not call this wrong per se. V3 has the meaning of ECO chip version and D0WD is a designation for chip features. You can also query the chip version separately and find that out. And I will not call it V3 migration issue, because we just added it to V3. It was not in V2 before. We can accept PR to change the print if it's really bugging you, but again, I do not consider that being wrong as it is now.

@mscott370
Copy link
Author

@me-no-dev Thanks for your speedy response. I would be was out of my depth in a discussion on the semantics and abbreviations involved in the Espressif product codes, but I do find this output misleading because it doesn't correspond to the ESP32 nomenclature in the (attached) ESP32 datasheet.
image
Additionally "D0WD" is now classed as "NRND", whereas "D0WD-V3" is still current/unblemished, which is likely to cause further confusion and misinterpretation.
My reference to migration was about IDF V4.4 to IDF V5 migration which impacted the esp_chip_info() function used in the getChipRevision() routine in ESP.cpp. The routine would have produced correct output with IDF v4.4 but needs change to produce same result with IDF v5.
I would like to see the output from ESP.GetChipModel() aligned with the ESP32 datasheet and the ESPTool.py output, so pls issue PR. Thank you for your help.

@me-no-dev
Copy link
Member

@mscott370 can you try the changes from this PR: #10243

@mscott370
Copy link
Author

@me-no-dev i just applied the two line changes manually to my local copy of ESP.cpp and am happy to confirm that it now works a treat!
Thanks again for your help.

@me-no-dev
Copy link
Member

Awesome. We will close the issue when the changes are merged

@mscott370
Copy link
Author

mscott370 commented Aug 26, 2024 via email

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
3.0 migration issue relates to migration from 2.X to 3.X version Status: In Progress Issue is in progress
Projects
Development

Successfully merging a pull request may close this issue.

5 participants
@me-no-dev @Jason2866 @mscott370 @VojtechBartoska and others