Firmware Update Compilation Error

Question

I just downloaded the newest firmware 1/25/2025 from today and I get the following error on compiling:

C:\Users\User\Downloads\EZ-ESP32-CAM (1)\EZ-ESP32-CAM\EZ-ESP32-CAM.ino: In function 'void doEZProtocol()': C:\Users\User\Downloads\EZ-ESP32-CAM (1)\EZ-ESP32-CAM\EZ-ESP32-CAM.ino:820:15: error: 'class HardwareSerial' has no member named 'setRxBuffer'; did you mean 'setRxBufferSize'? 820 | Serial2.setRxBuffer(8000); | ^~~~~~~~~~~ | setRxBufferSize exit status 1

Compilation error: 'class HardwareSerial' has no member named 'setRxBuffer'; did you mean 'setRxBufferSize'?

fxrtst · Answer

i tried to post this in the relevant firmware section of the EZB 32 CAM and it created a new thread?!

fxrtst · Answer

I changed it to "setRxBufferSize" and recompiled, uploaded ok. Need to change the firmware.

Athena · Answer

Good catch - that error is caused by a mismatch between the ESP32 Arduino core version and the firmware source. Newer cores use Serial2.setRxBufferSize(...) while older code (or older cores) used Serial2.setRxBuffer(...). Since you already changed it to setRxBufferSize and could compile/upload, that is the correct quick fix for modern ESP32 Arduino cores. Here’s a safe, simple summary and recommended next steps. What happened - The firmware source calls Serial2.setRxBuffer(...), but your ESP32 Arduino core does not have that member, so compilation fails. - Replacing the call with Serial2.setRxBufferSize(...) resolves the compile error with current cores. Quick patch (what you already did) - Open EZ-ESP32-CAM.ino - Find the line around doEZProtocol() (your error pointed at line ~820): cpp Serial2.setRxBuffer(8000);  - Replace it with: cpp Serial2.setRxBufferSize(8000);  - Recompile and upload - this worked for you. Better/safer options 1. Keep your local change and continue using the firmware (recommended if you need it working now). 2. If you want the official firmware updated so others don’t run into this: - Post the exact error and your change on the Synthiam ESP32-Cam firmware support page: https://synthiam.com/Support/Hardware/ESP32-Cam (Include firmware version/date, Arduino IDE/ESP32 core version you’re using, and the exact one-line fix.) - If you prefer, paste the change into the thread you already created and request that the firmware repo be updated - include the fix line above. If you’d like a more robust source that supports multiple core versions - A compile-time conditional would be ideal, but the ESP32 core doesn’t provide a single reliable macro that maps cleanly across all releases for "which method exists." Because of that, the simplest reliable approach is to standardize on the current API (setRxBufferSize) in the firmware source. If you need, I can draft a short conditional using a core-version macro - tell me which ESP32 Arduino core version you (and anyone else using the project) are targeting. Notes & tips - Before editing upstream firmware, make a backup copy of the original file. - Keep a note of the ESP32 Arduino core version you used for successful compile/upload - that helps when reporting the fix so maintainers can reproduce and update the repo. - If you need, I can prepare a small patch text (diff) you can paste into your thread or attach to the firmware page. Was your new thread created in the ESP32 CAM firmware support area or somewhere else? If it wasn’t in the correct support page, tell me the URL of the thread and I’ll guide you on how to move/duplicate the content to the ESP32-Cam firmware page so the maintainers will see it. Want me to: - produce a one-line patch/diff you can paste into the firmware thread? or - draft a short post you can copy into the ESP32-Cam support page with the error + fix + build details? Also, do you know which ESP32 Arduino core version you compiled with (Board Manager version)? That will help if we create a conditional or recommend an official commit.

Synthiam Support · Answer

I have disabled Athena on this thread because I advise creating a new thread and repost additional content for Athena to better assist. The error message without code is impossible for a human or AI to diagnose. When interacting with an AI, it's best to assume speaking to a human by providing the same information. An AI may generate its response from a vast amount of information, it is unable to imagine code that it can't see. LLM Prompting is slowly becoming a skill, and there's a bit of information here: https://synthiam.com/Support/website-features/How-To-Ask-Robot-Building-Questions 1) Define the outcome 2) Paste the error in a formatted code block 3) Paste the firmware code in a formatted code block Athena will rewrite the code in a new thread for you.

fxrtst · Answer

....ummm ok...I feel like everyone whether AI or not is missing the point. The new Firmware updated on 1/25 has an error. I dropped a note to bring attention. ( i fixed it on my end with the suggested fix from the IDE). I don't need Athena to do anything other that let the powers be, know that Firmware update for the ESP32CAM on 1/25 has the wrong Class HardwareSerial. I didn't want to start a new thread because in the old days (before AI) I could leave a response in the thread created for the firmware (where a request for the firmware repair should be, not a new thread). I can no longer do that and it creates a new thread (here) instead. I'll be sure not to report anything anymore because I hate all the AI. I spend so much extra time rewriting, reassuring or just plain saying the same thing multiple times. I'm going to start charging the AI for my time.  Just trying to help.

DJ Sures · Answer

Ah, I'm working with the ESP32 Wrover, and there's confusion between Support, Will, and the most recent firmware update in this thread. This is the frustration that open source is causing - and it's painful to experience. I'm on an ESP32 right now with this "ESP32 Wrover with camera". The thing is, both of you (Will and Support) are correct; the code for both of your experiences is correct. The class and the function are correct, depending on the version. There are multiple versions of the class, and each has its own naming convention. The firmware was created with a class that has a different method name. I'm dealing with that right now this evening, trying to get the "ESP32 Wrover with camera" to compile because the libraries have changed, yet again. Dear God, why won't they standardize on a naming convention?  I think what Support was getting at (without sharing the context) was that posting the source code would have Athena rewrite it to work for your needs. Same if you posted it in Chat GPT 5.2 (paid), you'll get it modified for your needs. You'd have to specify in the prompt, "I need this code modified for ESP32 Wrover with OV2640 Camera to work with ARC EZB firmware", and paste the code. Then, you'd get it modified for your needs. You see, if Synthiam ARC were to have firmware for every single ESP32- and Arduino-compatible device, we'd also need firmware for every single version of the SDK libraries. Exponentially, that would become hundreds of millions of firmware copies - obviously unrealistic. So specifically, if a firmware doesn't work, you'll have to understand that it did work for "something" at "some point" and needs tweaking to work for "something different" - just like what I'm doing now with ESP32 Wrover with a camera. Albiet, i'm rewriting it rather than using chat gpt because i have some ideas to enhance it.

fxrtst · Answer

Thanks for the clarification. This was just simple syntax error. The firmware had "setRxBuffer" and it was looking for "setRxBufferSize" At its request I changed it to setRxBufferSize and it compiled ok after that. And thanks for working on the ESP32 WRover and other enhancements! Once the firmware its locked down, could I not buy say 100 ESP's, upload the firmware to them, then there is no reason to change the firmware down the line? If it works today, why would it not work 5 years from now? Or is it the changes to the physical board that is the problem, or ever changing libraries? But again if I had a warehouse full of preflashed working ESPs they should work.  Maybe I'm missing something simple or obvious. Thanks again DJ

DJ Sures · Answer

It'll only need to be changed if you try to upload the firmware in a year or a week from now and they changed the ESP32 SDK. That's what is doing it - I know some of the ARC firmwares have specific mentions of ESP32 versions that must be used. The esp32 cam should have the same requirement, but it doesn't. I guess no time but the present.... I'll add the ESP32 version details to the firmware description and that should be useful in the future. Anyway, here's the latest firmware that i rewrote tonight with several bug fixes and improvements. Just look into the port mapping if you ever need to change to a different ESP32 camera module. Link with V9 firmware: https://synthiam.com/Firmware/ESP32-Cam-EZB-5KUNP4UTSW0

fxrtst · Answer

Whooo hoo! I’ll try it in the morning.. you seriously rock !

fxrtst

Upgrade to ARC Pro