It appears to be the v4.0 release, looks like I should actually go ahead and move to v4.0.1, but that does not seem to solve this particular issue.

Thanks! That makes sense. I guess related to this, all of my stack traces seem to get corrupted in this way (our panic handler uploads the stored-on-flash coredump to the server upon reboot)-- even testing by simply triggering an assert (e.g., assert(false);) leads to the current thread stack being ...

Your uploader is likely erasing the flash before it uploads.

How are you uploading your program?

So I seem to be getting somewhat random Panic resets in a device, it seems to be happening in crosscore? Complete core dump is here: https://pastebin.com/vCGet7eL So, the really weird thing is that this happened on devices that were at a customer's location, and two of them did this at precisely the...

vonnieda, I just wanted to drop in and thank you for your post! This solved a problem I was having (literally implementing the same post coredump to server). I want to note that the newer IDF version with the file in the ELF format does not need the first four bytes stripped. But the otherwise not r...

Any ideas on how they're doing dual ethernet? Does the RMII interface support multiple PHYs?

That's an interesting approach, actually!

I think we will stick with just storing the key in BLK3 (so it just lives on the device forever), and not treat it as a physical secret.

Thanks!

It seems likely that the aes hardware can read the key from the efuse, since that's how it works for encrypted flash, but I think it's just a matter of getting that API exposed to the point it can be used more generally.

Big picture, I would like to store a 256-bit key in the efuse and have the AES hardware read it directly from there (that is: have the efuse read-and-write protected). In my code now, we're just storing the key as a constant, so we initialize the AES context thus: esp_aes_setkey_enc( &context, &key,...

The uart_write_byte_with_break checks the length of the data and spits out an error on size 0. Currently looking for a solution for this, I use a protocol that starts packets with a BREAK...

Either allowing a 0 length data or a straight set_break command would be nice.