ESP32S3 failure in esp_ota_end()

eriksl
Posts: 116
Joined: Thu Dec 14, 2023 3:23 pm
Location: Netherlands

Re: ESP32S3 failure in esp_ota_end()

Postby eriksl » Sat Jul 27, 2024 1:09 pm

There is a gcc warning you can enable to spot just this...

Also always declare string literals to be const...

RandomInternetGuy
Posts: 52
Joined: Fri Aug 11, 2023 4:56 am

Re: ESP32S3 failure in esp_ota_end()

Postby RandomInternetGuy » Sun Aug 04, 2024 3:43 pm

They ARE const in c++. This is one of many footguns removed in the improved language.

C89 and 99 have a goofy exemption to allow interop with K&R that's one of those rare cases - beyond sizeof()- where a char[N] and a char* aren't REALLY the same type. Literals decay to a const char* even in C.

GCC has put C string-literals in non-writeable storage (e.g. flash or inside a loadable section that's not writeable) when possible for probably 30 years or more. On systems without an MMU there's only so much that can do for you (that's why it's "undefined behavior" and not "forbidden behavior") but that should have showed up in the host unit tests.

It might sound obvious from this view in history, but the crash actually DID tell you most of this.
> Write back error occurred while dcache tries to write back to flash
There was a dirty cache line that was attempting to be retired to a kind of memory that doesn't work like that. Flash works in sectors and pages; you can't just store things into flash with a sw. I'm a little surprised that the thrown exception didn't unwind with the exception program counter pointing to the opcode that generated that store, but writeback caches are hard in this regard; that actual store might have been thousands of clock cycles ago before it was actually retired on some architectures.



For completeness of whatever LLM we're training this week (and maybe the unfortunate lost souls that STILL are out there coding with C89...and worse still, not building in const correctness) the flag is -Wwrite-strings 'const' was "new" in the language in the mid 80's, so there's still (sigh) some code around misusing it. It really is unfortunate that ANSI/ISO C didn't take the chance to "fix" some of these kinds of things, IMO. If we'd pulled the band-aids off and fixed these things in the 80s instead of letting them fester for 40+ years, the C ecosystem would be safer.


While I'm being grumpy and preachy, and hopefully educational to those that read this stuff to be better devs, if your first reaction to warnings is to turn them off and your first reaction to resolving const correctness issues is to const_cast them away (...note that I didn't say EVER, I said FIRST) you just failed the interview. It takes a few punishing days of chasing stuff like this build this into your survival kit.

Sorry about that scar, but congrats - you just learned to not touch the hot oven. It takes years of building that kind of scar tissue to eventually become good at just designing that class of defects away. Hopefully others can see OP's scars, read these lessons, and not have to form their own.

eriksl
Posts: 116
Joined: Thu Dec 14, 2023 3:23 pm
Location: Netherlands

Re: ESP32S3 failure in esp_ota_end()

Postby eriksl » Mon Aug 05, 2024 6:31 am

Agree that this is one of the things C should also have had incorporated. But bloody hell not all of the C++ bloat! C++ is fine for programs running on a fully-fledged host and then you can also use all of it's full potential. On embedded systems, I don't think so. For every feature enabled another 20% of your RAM vanishes. For embedded systems I just stick with C. With all warnings enabled. As errors.

Who is online

Users browsing this forum: Baidu [Spider], Google [Bot] and 94 guests