Asked

Alternative To Ezrobot Ezb For Robot Head Project

My course has primarily focused on robotics projects using the EZ-B controller and a camera for real-time interfacing. With recent developments, I am planning to create an additional video that incorporates Synthiam's support for other types of controllers. Although I've successfully flashed an alternative controller, it lacked compatibility with camera integration and Wi-Fi capabilities. The absence of an onboard computer limits the use of a USB camera, posing a significant challenge.

This dependency on specific components like the EZ-B, IO Tiny, and cameras can be problematic. For my course project, Mecha Morphix, which involves controlling five servos, the Arduino Mega seems excessive. I am in search of a suitable controller, compatible with Synthiam ARC, that includes both Wi-Fi and camera support to effectively replace the EZ-B.

I noticed that the ESP32 with a camera is listed among the supported controllers for ARC. Has anyone experimented with using the ESP32 in conjunction with a camera for such applications? Any insights or experiences would be appreciated.


Related Hardware ESP32 Cam

ARC Pro

Upgrade to ARC Pro

Synthiam ARC Pro is a new tool that will help unleash your creativity with programming robots in just seconds!

Author Avatar
PRO
USA
#57  

What I find interesting is that the DoIt ESP32 Dev V1 used the default IP in ARC (192.168.1.1:23) And for the ESP 32 CAM I have to look for the IP via serial monitor and enter that in ARC to connect. Is there something in the DoIt sketch that assigns 192.168.1.1:23 IP to the board? And its not in the sketch for the ESP32 CAM board? I think by default the boards ship with an IP of 192.168.4.1. Both boards are in AP mode. Just asking to be informed.

Author Avatar
PRO
Canada
#58  

Nice troubleshooting - glad you got it working with the AI-Thinker selection and can stream both OV2640 and OV3660. Here’s a clear explanation of why you saw different default IPs/ports and what controls them, plus how to make the behavior deterministic.

Why the IP / port differed between boards

  • Boards themselves do not "have" a permanent IP. The IP you see is chosen by the firmware running on the ESP32, or by the network (if the ESP32 is in STA mode).
  • AP mode default for the ESP32 Arduino WiFi library is 192.168.4.1. That’s common, but firmware can change it with WiFi.softAPConfig().
  • Some custom firmwares set a different AP IP (e.g. 192.168.1.1, 192.168.50.1) - Synthiam or other vendor binaries sometimes choose a different subnet. That explains why your DoIt board appeared as 192.168.1.1 while the ESP32-CAM reported 192.168.4.1 (or 192.168.50.1 in your case).
  • If the ESP32 is in STA mode it will get an IP assigned by the router (e.g. 192.168.1.x). Different mode different IP behavior.
  • Port numbers are also set by the firmware. Synthiam EZB-style camera stream commonly uses port 24 for the EZB stream, but other example sketches or services (telnet-like, raw serial-over-TCP, or different firmware) might use port 23 or another port. ARC will remember previously used camera URLs and show them in dropdowns, so you may see a stored 192.168.1.1:23 entry from earlier usage.

How to determine the right IP and port (best practices)

  1. Always check the Serial Monitor at 115200 after boot - the firmware prints WiFi mode, assigned IP, and server/listen port. Paste that text if unsure. I can interpret it for you.
  2. If in AP mode, connect your PC to the ESP32 AP SSID (so your PC IP is in same subnet) and ping the device (ping <ip>).
  3. Use ARC’s Camera Device Custom and enter the exact EZB URL:
    • EZB://<ip> or EZB://<ip>:24 (replace <ip> with the serial-printed IP and use the port reported by the firmware).
  4. If you want ARC to discover it automatically, make sure the firmware advertises the service or run the ESP32 in STA mode on the same router as your PC so it appears on the router subnet.

How to set a specific AP IP and port in firmware (Arduino example) If you want a deterministic AP IP, add WiFi.softAPConfig() in the ESP32 sketch before softAP() is started. Example:

#include <WiFi.h>

IPAddress local_IP(192,168,50,1);     // desired AP IP
IPAddress gateway(192,168,50,1);
IPAddress subnet(255,255,255,0);

void setup() {
  Serial.begin(115200);

  // set SoftAP config BEFORE softAP is started
  WiFi.softAPConfig(local_IP, gateway, subnet);
  WiFi.softAP("ESP32CAM-MyAP", "mypassword");

  Serial.print("AP IP=");
  Serial.println(WiFi.softAPIP());

  // ... camera init and server start here ...
}

If you need the EZB camera server to listen on a specific port, that is defined by the server code in the firmware - you’d change the port there (e.g., the TCP server listen port). If you want, I can point to the exact lines in the Synthiam firmware or show a small sample of how to start a TCP server on port 24.

Practical tips and next steps

  • ARC sometimes shows previously used camera strings; if you used a DoIt binary earlier, ARC might have saved that IP:port combo. Always replace it with the IP the board actually prints on serial.
  • If you want a single predictable setup for your course (handy for students), reflash the ESP32 firmware to use a fixed AP IP (as above) and ensure server uses port 24 - then provide them the exact EZB://192.168.50.1:24 string. I can prepare that change for you.
  • Use Synthiam’s network scan feature in the Camera Device skill as another way to find EZB streams on the same network: https://synthiam.com/Support/Skills/Camera/Camera-Device?id=16120
  • Synthiam ESP32 docs / firmware page (reference): https://synthiam.com/Support/Hardware/ESP32-Cam and the firmware download page you used.

Would you like:

  • A quick patched firmware you can flash that sets AP IP to 192.168.50.1 and forces the EZB camera server port to 24? (I can prepare instructions and the code snippet.)
  • Or the exact lines in the Synthiam prebuilt binary to confirm what IP and port it uses (paste your serial output and I’ll decode it)?

Which would help you most for Mecha Morphix and the servo + camera test?


I am a customer support GPT-powered AI and still learning. If you have doubts about my response, please use the support documentation to verify my answer.
Author Avatar
PRO
USA
#59  

No servos are working on this version of the board (ESP32 CAM) currently. I can get camera to work no problem. But moving through the pins D2, D12, D13, D14, D15 and no movement on hooked up servo. I have the servo power from a power supply, sharing a ground between the ESP32 and power supply. I am then setting up a test range of pins one at a time with the signal wire, and changing it in ARC along the way. Zero servo movement. The servo has power as i can here it hum.

I also tried to flash the Freenove ESP32 S3 CAM Board, but in the IDE i get the following message: Sketch uses 1009665 bytes (32%) of program storage space. Maximum is 3145728 bytes. Global variables use 67324 bytes (20%) of dynamic memory, leaving 260356 bytes for local variables. Maximum is 327680 bytes. esptool.py v4.6 Serial port COM4 Connecting....

A fatal error occurred: This chip is ESP32-S3 not ESP32. Wrong --chip argument? And stops the upload to the board.

Author Avatar
PRO
Canada
#60  

Great - glad the camera is working. Let’s get the servos moving and the flashing error resolved. Below I’ll cover the most common causes, quick tests you can run from ARC, and the fix for the ESP32S3 flashing error.

Summary of likely causes

  • The EZB firmware you flashed may not expose servo (PWM) on the pins you’re trying, or that ESP32 model’s GPIOs are used by the camera and can’t produce usable servo PWM.
  • Wiring/power/ground issues (you already have external power and common ground - good).
  • Wrong board/core selected when flashing an ESP32S3 (that causes the esptool error you saw).

First quick checks (run these in ARC Script control)

  • Verify ARC can see the EZB (ESP32) connection:
print("EZB connected? " + EZB.isConnected(0));
  • Try toggling a pin as a digital output to confirm ARC can control the physical pin (use the D port constant). This only checks GPIO control - not a servo PWM:
// test D2 -> set high for 250ms then low
Digital.set(d2, 1);
sleep(250);
Digital.set(d2, 0);
print("Digital toggle done");
// set servo on d2 to 90 degrees
print("Move servo to 90");
Servo.setPosition(d2, 90);
sleep(1000);
print("Move servo to 0");
Servo.setPosition(d2, 0);

Notes: use d2 without quotes (port constant). If these commands do nothing (no voltage change on D2 for Digital.set and no servo movement for Servo.setPosition), continue below.

Troubleshooting steps in order

  1. Confirm firmware supports servos on that ESP32 build
  • Which firmware binary did you flash? (Synthiam ESP32Cam EZB firmware vs. a different sample binary)
  • If you used Synthiam EZB firmware (recommended), it should implement Servo.* commands - but some ESP32 CAM modules reserve many GPIOs for camera and do not support PWM on all pins.
  • If you flashed a nonEZB camera binary, it may not implement the EZB servo/PWM commands at all.

Action: Reflash with Synthiam ESP32Cam EZB firmware from: https://synthiam.com/Support/Hardware/ESP32-Cam (or confirm you used that exact bin). If you didn’t, flash the Synthiam EZB firmware and retest.

  1. Pin conflicts: camera vs servo pins
  • Some ESP32-CAM modules use many GPIOs for the camera and those pins cannot be used for servo PWM while the camera is active.
  • The manual mentions: "On the AI Thinker edition, servos work on D2, D12, D13, D14, and D15. However, you will need to try your edition/model to see if those pins work."
  • Even on AIThinker, results depend on module variant and wiring.

Action:

  • Try the recommended list again (d2, d12, d13, d14, d15) - you did - but also try to confirm which physical pin is which GPIO (board silk vs label vary).
  • Use a multimeter or LED to see if Digital.set actually toggles the pin voltage (step above). If Digital.set toggles but Servo.setPosition does not move servo, the firmware may not implement PWM for that pin while camera active.
  1. Confirm servo signal voltage & wiring
  • Servos need a stable V+ (often 5-6 V). Signal at 3.3 V from ESP32 is usually fine. You mentioned hearing hum (likely the servo powered).
  • Ensure common ground between external servo supply and ESP32 GND (you said you have it - double-check the ground truly connected).
  • If the servo hums but does not move, it may be receiving PWM but stuck at mechanical limit or insufficient power under load.

Action:

  • With no load on servo, power it from the external supply. Manually flick the servo horn to detect torque. If it’s weak, increase supply capability.
  • Use a logic probe/multimeter to check PWM presence on signal pin when running Servo.setPosition.
  1. Test servo control with no camera (diagnose camera conflicts)
  • Stop the camera in ARC (Camera skill -> Stop).
  • Run the Servo.setPosition(d2, 90) test again while camera is stopped. If servo works when camera is off, you have a camera/GPIO conflict and must use a different pin or different hardware.
  1. If Digital.set works but Servo.setPosition never moves
  • The building block: firmware must implement servo/PWM on that GPIO. If firmware does not enable servo on those pins while camera is active, you’ll need:

Recommendation (practical & robust)

  • If you want reliable servo control while using the camera, use a small external servo controller (PCA9685 I2C 16channel) powered from the servo supply. Connect the PCA9685 to the ESP32 I2C pins (that aren’t used by camera) or run the PCA9685 on a separate microcontroller and use UART/I2C to ARC. ARC has PCA9685 controls via robot skills or via I2C commands. This avoids GPIO conflicts and gives stable servo PWM and more channels for Mecha Morphix.
  • Or use the Single Camera servo Server robot skill (you already have it) with a separate controller for servos.

ESP32S3 flashing error and fix

  • Error you saw: "This chip is ESP32S3 not ESP32. Wrong --chip argument?"
  • Cause: You selected an ESP32 (ESP32) board in Arduino IDE but the board is actually an ESP32S3 variant. The esptool needs the correct chip argument. Fix:
  1. Install the latest ESP32 board support package that includes S3 support:
    • Arduino IDE: Tools -> Board -> Boards Manager -> search "esp32" (by Espressif). Install latest (it includes esp32s3 variants).
  2. Choose the correct board for an S3 CAM (e.g., "ESP32S3 Dev Module" or Freenove’s listed board if available).
  3. If you see a specific Freenove board in the Boards list (Freenove ESP32S3 CAM), choose that.
  4. Then flash again. The correct board selection will pass --chip esp32s3 to esptool and the upload will succeed.

If you prefer esptool CLI, add --chip esp32s3 to the command: esptool.py --port COM4 --chip esp32s3 write_flash ...

Follow-ups I need from you (so I can give exact next steps)

  1. Which exact Synthiam/thirdparty firmware binary did you flash to the ESP32CAM? (link or filename)
  2. Which ESP32 CAM board variant are you using now? (AIThinker, TTGO, AzDelivery, model name printed on PCB)
  3. Which physical pins (silkscreen/GPIO numbers) did you hook the servo signal wire to? (If you say "the pin labeled D2" tell me the board’s silk label - e.g., IO2/GPIO2)
  4. Does Digital.set(dX,1) show a voltage change on the pin? (Yes/No)
  5. Does stopping the Camera skill in ARC allow servo movement (try Servo.setPosition while camera stopped)?

If you want, try this short Script in ARC (it will test digital toggle, then attempt servo movement while printing results):

// Quick hardware test - change d2 to any port you want to test
print("EZB connected? " + EZB.isConnected(0));
print("Toggling digital pin d2");
Digital.set(d2, 1);
sleep(250);
Digital.set(d2, 0);
sleep(250);
print("Attempt servo move to 90");
Servo.setPosition(d2, 90);
sleep(1000);
print("Attempt servo move to 0");
Servo.setPosition(d2, 0);
print("Test complete");

If all else fails (servos never move while camera running and the Digital toggles also do nothing), I strongly recommend using a dedicated servo controller (PCA9685) or a small WiFi microcontroller (another ESP32/ESP8266 or small ESP32S2/S3) dedicated to servos and have ARC control it via I2C/UART/EZB protocol. I can guide you stepbystep on:

  • Wiring and ARC configuration for PCA9685, or
  • Creating a tiny EZBcompatible firmware that exposes the servo pins you need.

Which do you want to try next?:

  • Reflash Synthiam EZB firmware and re-test (I can give the exact firmware link/instructions), or
  • Run the short Script above and paste the results, or
  • I’ll show how to wire a PCA9685 servo board and configure ARC to control 5 servos reliably.

I am a customer support GPT-powered AI and still learning. If you have doubts about my response, please use the support documentation to verify my answer.
Author Avatar
PRO
USA
#61  

I 'm now trying out the Freenove ESP32 Wrover and it flashes ok using the library: ESP32S3 Dev Module

I get this reboot loop over and over after uploading:

ELF file SHA256: 3f9f1ef00900ef81

Rebooting... ESP-ROM:esp32s3-20210327 Build:Mar 27 2021 rst:0xc (RTC_SW_CPU_RST),boot:0x2a (SPI_FAST_FLASH_BOOT) Saved PC:0x4037ba36 SPIWP:0xee mode:DIO, clock div:1 load:0x3fce3818,len:0x109c load:0x403c9700,len:0x4 load:0x403c9704,len:0xb50 load:0x403cc700,len:0x2fe4 entry 0x403c98ac

Guru Meditation Error: Core 1 panic'ed (LoadProhibited). Exception was unhandled.

Core 1 register dump: PC : 0x4204fd15 PS : 0x00060830 A0 : 0x82048f94 A1 : 0x3fceba50
A2 : 0x3fca5e14 A3 : 0x3fc9faac A4 : 0x3c0b6174 A5 : 0xffff8fff
A6 : 0x00000001 A7 : 0x00000000 A8 : 0x80377ddf A9 : 0x3fceba60
A10 : 0x00000016 A11 : 0x00000000 A12 : 0x00000008 A13 : 0x00000060
A14 : 0xb33fffff A15 : 0x00000000 SAR : 0x0000001f EXCCAUSE: 0x0000001c
EXCVADDR: 0x00000000 LBEG : 0x400570e8 LEND : 0x400570f3 LCOUNT : 0x00000000

Author Avatar
PRO
Canada
#62  

Nice detail - that reboot loop + Guru Meditation tells us the chip is crashing early in setup (LoadProhibited usually means code tried to read a NULL pointer or invalid memory). Let’s narrow it down and get a stable board again.

Likely causes (high priority)

  • Wrong board or core settings in Arduino IDE (ESP32-S3 needs S3-specific core & options).
  • PSRAM expectations: camera code often requires PSRAM; if PSRAM not enabled or not present, camera init can crash.
  • Camera driver / pin mapping incompatible with the board variant (camera init touches invalid memory).
  • Firmware built for a different chip/variant or using features unsupported on your module.
  • Faulty hardware or wiring (less likely if it flashes ok, but still possible).

Step-by-step plan to diagnose and fix

  1. First confirm the board can run a minimal sketch (rule out hardware/board/core toolchain problem)
  • Upload this minimal blink test (select Tools Board: "ESP32S3 Dev Module" or the correct S3 board). If this sketch also reboots, there’s a board/core mismatch or hardware issue.
// Minimal Blink test for ESP32-S3
void setup() {
  pinMode(13, OUTPUT); // pick a safe pin like 13, change if needed for your board
  Serial.begin(115200);
  Serial.println("Blink test start");
}

void loop() {
  digitalWrite(13, HIGH);
  delay(500);
  digitalWrite(13, LOW);
  delay(500);
}
  • If blink is stable: hardware/core basics are OK - crash is in the firmware you flashed (camera init).
  • If blink reboots: toolchain/board selection/hardware issue. Re-check Boards Manager entry for esp32 package and try reinstalling or a different release.
  1. Check/enable PSRAM correctly (camera firmwares often require PSRAM)
  • In Arduino Tools, enable "PSRAM" if the board has it (Wrover modules usually do).
  • If PSRAM is disabled but firmware expects it, camera init can panic with LoadProhibited.
  • If the module does NOT actually have PSRAM, disable PSRAM and flash an appropriate binary that doesn’t use PSRAM.
  1. Use the right board selection & flash options
  • Install latest Espressif ESP32 Arduino core (Boards Manager). Recent S3 support is in esp32 core v2.x+.
  • Choose the correct board under Tools:
    • If generic S3: "ESP32S3 Dev Module"
    • If Freenove provides a board entry choose their Freenove S3 CAM if available
  • Typical Tools recommended values:
    • Flash Mode: DIO
    • Flash Frequency: 80MHz
    • Partition Scheme: Default
    • PSRAM: Enabled (only if module has PSRAM)
  • Rebuild/upload after verifying settings.
  1. If you flashed a camera sketch or 3rd-party firmware, try disabling camera init
  • If you have source code, comment out camera initialization and re-upload to see if board boots stable. If stable, camera init is the crash source (pin mapping, driver or PSRAM).
  • If using a prebuilt binary, try a different binary (e.g., Synthiam’s ESP32 Cam EZB firmware) that’s known to work with ARC: https://synthiam.com/Support/Hardware/ESP32-Cam
  1. Decode the exception for exact location
  • Use the ESP Exception Decoder plugin for Arduino IDE (or the online decoder) to map the addresses in the backtrace to the source line. This tells you which function caused the crash.
  • How to use: copy the Serial Monitor output (the full panic stack) into the decoder - it will show the function/file/line in your compiled sketch or library.
  1. Try a different core version if problem persists
  • Some camera libraries or camera board support had regressions or differences across esp32 core versions. Try installing an earlier or later esp32 board package in Boards Manager and rebuild.
  1. If you want a quick working route for ARC use:
  • Flash the Synthiam ESP32-CAM EZB firmware (prebuilt) for AI-Thinker/ESP32-CAM variants and confirm it boots and prints the camera server lines on serial. That binary is tested for ARC.

Questions I need to help further

  1. Which exact firmware/sketch did you flash that produces the reboot loop? (filename or GitHub link).
  2. Which exact board/module variant is this (Freenove S3 CAM, AI-Thinker, DoIt, Wrover, etc.)? Does it have PSRAM (Wrover usually does)?
  3. Can you paste the full Serial Monitor output from boot (from power-on to panic) - do NOT post images; paste the text.
  4. Did the minimal blink test succeed or also reboot?

If you paste the Serial Monitor panic output I’ll:

  • Decode the trace for you (if you also indicate which .elf / sketch produced it or compile with map so the exception decoder can map addresses), or
  • If you can’t provide .elf, I’ll still point at the most probable culprit (camera init / PSRAM).

If you’d like, next steps I can prepare for you

  • A step-by-step flash recipe (exact Tools settings) for Freenove S3 CAM that tends to avoid the reboot loop.
  • A short camera-less firmware to test PSRAM presence and show how to safely enable camera initialization once PSRAM / pin mapping is correct.
  • Help flashing Synthiam’s tested EZB firmware for ESP32-CAM so ARC can connect immediately.

Which do you want me to provide next? (If you paste the serial panic text now I’ll analyze it and recommend the concrete fix.)


I am a customer support GPT-powered AI and still learning. If you have doubts about my response, please use the support documentation to verify my answer.
Author Avatar
PRO
USA
#63  

I'm consuming my valuable time around the controller and camera combo, when the reality is, there are a million ways to get a camera to work with ARC these days, from webcams to wifi cams and so on. So I'm going to focus on only the controller and ARC aspect. All works works fine on the Do It ESP32 Dev v1 board, I just need to get the Freenove (or other board) working with ARC.

I still have 1001 things left to do for the Mecha Morphix launch and have no spare time to fall deep into this endeavor..for now.

Author Avatar
PRO
Canada
#64  

Good plan - concentrate on the parts that move your Mecha Morphix forward and avoid getting stuck chasing every board/camera combination. You’ve got a working setup (Do It ESP32 Dev v1) - keep using that for development and demos. Below are concise, actionable options and a short "when you come back to this" checklist so you can finish the Freenove / other board work quickly when you have time.

What I recommend now

  • Continue development and demos with the Do It ESP32 Dev v1 (since it already works with ARC).
  • Defer the Freenove / S3 board deep-dive until you have time; use a small checklist later to get it stable quickly.
  • If you plan to use servos with camera in the final Mecha Morphix hardware, use a dedicated servo driver (PCA9685) to avoid camera GPIO conflicts and unstable PWM from camera driver pins.

Quick reasons:

  • Many ESP32-CAM pins are grabbed by the camera and can’t reliably output servo PWM while streaming. A PCA9685 (I2C) gives stable PWM, 16 channels, and isolates servo power from camera/ESP32 power noise.

Useful links

Quick "return-to-work" checklist (when you have time)

  1. Decide whether you’ll use a Synthiam prebuilt EZB firmware (fastest) or build your own:
    • If prebuilt: flash Synthiam’s ESP32-CAM EZB binary (tested for ARC).
    • If building: ensure you include the EZB protocol component and correct camera pinmap for your module.
  2. For ESP32-S3 / Freenove S3 boards:
    • Install latest Espressif board package in Arduino Boards Manager (ensure S3 is supported).
    • Select the correct board (e.g., "ESP32S3 Dev Module" or Freenove-provided board).
    • Set Tools: Flash Mode = DIO, Flash Freq = 80MHz, Partition = Default.
    • Enable PSRAM only if the module has PSRAM and your firmware uses it (camera libs often require PSRAM).
  3. Fixed AP IP & port (makes student setup deterministic):
    • Add WiFi.softAPConfig(local_IP, gateway, subnet) before softAP() in your sketch to force the AP IP (example below).
    • Ensure the camera server is started on the port you want (Synthiam EZB camera commonly uses port 24).
  4. Verify on serial monitor (115200): firmware should print WiFi mode, AP IP, and "server listening on port X". That is always the first diagnostic.
  5. Network test from PC:
    • PowerShell: Test-NetConnection -ComputerName 192.168.50.1 -Port 24
    • If it times out, check Windows firewall / VPN / WiFi network / PC routing.
  6. ARC quick-test (Script control):
    • Start camera: ControlCommand("Camera","CameraStart","EZB://192.168.50.1:24")
    • Use Test Script below to check GPIO and servo.

Small ARC test scripts (paste into ARC Script control)

  • Digital toggle test:
print("Digital toggle test on d2");
Digital.set(d2,1);
sleep(250);
Digital.set(d2,0);
print("Done digital toggle");
  • Servo test (attempt servo move; substitute port if needed):
print("Servo test: move d2 to 90");
Servo.setPosition(d2,90);
sleep(1000);
Servo.setPosition(d2,0);
print("Servo test done");
  • Start camera via script (use your board IP/port):
print("Starting camera via ControlCommand");
ControlCommand("Camera","CameraStart","EZB://192.168.50.1:24");
print("Start command sent");

If servo is not moving while camera is running

  • Stop the Camera skill in ARC and re-run the servo test. If the servo moves with camera stopped, you have a camera GPIO conflict and should use a PCA9685 or separate microcontroller for servos.
  • If Digital.set toggles the pin voltage but Servo.setPosition has no effect, the firmware may not expose PWM on that pin - firmware pin mapping matters.

If you’d like, when you have spare time I can prepare one of these for you:

  • A short prebuilt firmware patch (or exact flash instructions) that sets AP IP to 192.168.50.1 and forces the EZB camera server to port 24 (so you can distribute a single EZB:// address to students).
  • A concise wiring + ARC setup guide for PCA9685 powering 5 servos (I2C wiring, power grounds, and ARC servo mapping).
  • Exact Arduino IDE Tools settings for Freenove S3 so you stop hitting the reboot loop (PSRAM + board selection notes).

Which is most helpful to have ready for you later - the fixed-IP/port firmware, the PCA9685 wiring guide, or the Freenove flash settings?


I am a customer support GPT-powered AI and still learning. If you have doubts about my response, please use the support documentation to verify my answer.