in my experience not having publicly-available documents seem to mostly affect those hobbyists and very few professionals. There's a large middle ground between "professional" and "hobbyist", and a lot of important software is developed by people in that middle ground. An NDA requirement is a prett...

You could write it in C, once it works save assembly code, edit, assmble it, make sure it still works I haven't looked — is there actually an assembler/disassembler in the toolchain? Of course, trying to learn a completely new instruction set by reading disassembly is not my idea of fun, or even my...

I'm looking for documentation of the ESP32 instruction set, for assembly language programming. I've found some old (2010) Xtensa ISA docs, but their designs are so configurable that it's not much use for a specific CPU. I've seen two threads from a few years ago asking about this, and replies from E...

When I run "make size-files" (with CONFIG_OPTIMIZATION_LEVEL_RELEASE) I see that a lot of the top contributors to the binary size are related to C/C++ locale handling: Per-file contributions to ELF file: Object File DRAM .data & .bss IRAM Flash code & rodata Total ... locale-inst.o 0 144 0 25655 723...

FYI, I've filed an IDF issue on Github.

Of course, right after asking I found a (partial) answer. I can configure the program to log a core-dump when it crashes, and then read that dump into gdb. Then I can use the `info thread` and `thread` commands to view and switch to different threads/tasks. It even shows what the parameters and loca...

Debugging with the gdb stub is very useful. But I can only see the thread/task that crashed, not any others -- `info threads` only shows that thread. I'm trying to debug a problem where a thread is hung inside system code (`select`), and while I can easily make another task force an exception and dr...

Looking through the spi_flash sources I found calls to a Cache_Flush() function; this looked promising, so I added to my code just after calling esp_partition_write(). That appears to have fixed the problem.

Yeah, that's what I'm thinking too; as I wrote above:

My only other hypothesis is that this is due to CPU cache coherency, but the spi_flash code looks like it's careful to disable/enable caches.

However I have no idea what additional cache might be at fault, nor how to flush it.

My app will sometimes just freeze -- it stops logging and responding to network requests. I'd like to interrupt it and drop into the GDB stub and look at the thread/task stacks. Is there a way to do this? I can't find a monitor command for it. My dev board (a SparkFun ESP32 Thing) has two physical b...