crc error esp32c3 nimble

[Mebius84]

Hi. When i use nimble i can`t upload firmware via web app, i always get crc error, but with stock bluedroid it work fine!
i use esp32c3 and last bleota, i try to use it with last platformio, last pioarduino, add nimble-arduino lib from pio, nothing work(((

Temporary solution, hardcode MTU 247 value in web app code
client: chrome android

how can i fix it?

[dougbert-b]

I saw the same CRC error last week when I tried to use the web app in Chrome on an Android phone. But when I used Chrome on a Windows PC, it worked fine. And about a month ago, it also worked on Android...

[dougbert-b]

The "hardcode MTU 247" workaround works for me too: I can now do OTA updates with Chrome on Android.
Also, the upload speed increased quite a bit, from about 6 kB/sec with the stock uploader to 15 kB/sec.

[gb88]

Is more likely a problem of webBLE or Espressif stack during MTU negotiation i think

[ll3u]

I came across exactly the same issue today and can confirm the symptom - coming from an ESP32-C3-Zero (ESP32 Arduino Core 3.x, NimBLE) with BLEOTA 1.0.6 - trying to flash firmware from android with the latest cromite.

logs (same pattern as OP)

[05:28:14] MTU probe → payload=507B/packet
[05:28:14] FW NACK sector 0: Cannot start OTA <--
[05:28:30] START FLASH size=416693
[05:28:30] CMD_ACK ok (cmd=0x1)
[05:28:30] OTA accepted, transferring…
[05:28:30] FW NACK sector 0: CRC error
[05:28:30] Error: Sector 0 failed after 3 attempts

The MTU probes 507B, CMD_ACK ok succeeds, but sector 0 instantly fails CRC. So the WebApp should not just "trust" the 510-byte probe on mobile browsers. If the browser is Android or iOS, the MTU probe could be capped at 247 bytes (or 185 bytes) to prevent the OS from silently truncating the packets.

The workaround for me is to resolve PKT_PLOAD based on the user agent, capping the MTU probe at a "mobile-safe" value before starting the transfer like this:

function getMtuCap() {
  const ua = navigator.userAgent;
  if (/Android/i.test(ua)) return 185;   // safe for Android
  if (/iPhone|iPad|iPod/i.test(ua)) return 247;
  return 507; // desktop
}

With payload=185B/packet the OTA completes successfully on the same phone + same browser combination that was failing before. Once I drop that cap, it fails again immediately.

A more robust fix might be on the firmware side: have the ESP32 validate the first received packet against the negotiated MTU and, on repeated short-packet / CRC failures at sector 0, request a smaller MTU rather than NACKing out. That way the fix doesn't depend on the WebApp guessing the "right" cap.

[gb88]

@ll3u if you have a fix to propose please send a pull request, thanks