Hi Ye,
You do know how to dig into a problem, bravo!
Yes in fact at one point printf/scanf was replaced by a custom formatter function which didn't cause the data corruption... but that only hid the underlying problem and eventually it caught up. Granted that printf/scanf with floats/doubles is a known trouble-maker... many would tell you never to use it in embedded systems like this. But when it works, it works fine, "just" eats a bit of heap space while it's working.
Anyway, I recently discovered that the RUN_TASK stack is not aligned properly in the . Somehow it escaped the ""
of 2015. Right now it doesn't seem to be affecting anything with the CW builds, but with the different toolchain, who knows.
So I would start there and bump it up to 256. Ideally this will cure it. There's also a chance it will cause some other structure which is used within runTask to become misaligned... and there are quite a few.
My current working version has all this fixed (I hope)... and lots of the major structures re-aligned properly. (Speaking of RAM, this actually resulted in a nice net gain of a few % in available CCM & SRAM.) But this is all part of a whole slew of changes I've been working on. I'm just now starting to break it up into sensible commits to new feature branches (which is tricky when you re-arrange a quarter of the header files
).
So, if fixing the RUN stack doesn't fix it quickly, maybe I should send you what I'm working with now. It's all slated to be pushed to GH anyway at some point soon, but you know how that goes...
Best,
-Max