It's undefined, as in, we don't guarantee anything about the state the data is in. In practice, it may be that the first few words still are 'old' data as they're already hoovered up by the DMA subsystem and waiting in a FIFO somewhere, but whatever behaviour you see, better not depend on it as ther...

No, sorry, the USB serial/JTAG unit cannot be renamed. However, the ESP32S3 also has an USB OTG peripheral, switchable to use the same port. That hardware does allow for reconfiguration. (You probably want to look into the TinyUSB examples, I think that has some stuff with custom descriptors.)

The errors you mention all sound like IDE issues. Have you actually tried compiling the project? For the first run, CMake resolves a bunch of dependencies etc, without that IDEs are generally incapable of finding everything.

?

Agree, I'll move it to there.

Hard to say. For issues like this, you generally want to own at the very least a cheap logic analyzer, or they get very hard to debug.

Ah, never mind, I thought you used the USB-serial-JTAG converter; if you're using an UART to program the chip, my advise is not applicable. In that case, I don't have specific advice. Suggest you check the power rails, if the UART signals look good, etc, perhaps there's an issue there. You could als...

You would use a critical section (docs).

It's possibly easier to create a FreeRTOS task for this. Task waits for e.g. a semaphore or queue, then handles the sensors. Either your interrupt or your normal code can raise the semaphore or put something in the queue and let the task handle the thing.

Smells like something is not properly re-entrant, which causes the spurious errors. Is there a way to handle the cancel in the download task, as in, the cancelling task raises a semaphore, the download task checks that and calls esp_http_client_close() function?