Building with GCC - success!

[aBUGSworstnightmare]

I would check the .map files to find out about memory usage/free memory...
How long time will it take you to figure out how many WPs you can/want to use? You can download a 30days full featured eval version of Crossworks so no need to spend 150bucks for figuring this out.

By the way: do you live in your business rooms? License CW for your private use (home address). As long as you don't start earning money from your Personal Non-Commercial License nobody/will care how and where you use it (ever heard of 'bring your own device' --> no problem to take your PC with you wherever you want to ...)

[Max]

Ye, this bring up a point I've been meaning to mention. The ARM architecture, as you may know, requires proper memory alignment of data structures (in 32-bit registers in the case of STM32). For AQ specifically, this means all stack sizes have to be multiples of 8, and in many cases how the variables are laid out in the data structs (eg. navData, controlData, etc) can make a difference as well.

When alignment isn't correct, the problem may (or may not) manifest itself in different ways. The first "victim" seems to always be printf/scanf, which start corrupting the output/input when dealing with floats/doubles. If the misalignment is "bad enough" it will lead to random crashes or lockups.

printf/scanf are mostly used in AQ for writing/reading params from DIMU EEPROM and SD card file. So, a good test of alignment (after making changes or whatever) is to do a test write/read of params to/from SD. It is immediately obvious when something is wrong because all the numeric values (the floats) have unreasonable values (most are FLOAT_MIN it seems like, but it varies).

Saving calibration params to EEPROM can also reveal the issue, but having corrupt data in IMU settings can cause other problems, so that test is best saved for last after writing to SD is sure to work.

So, in your testing with GCC, could you (if you haven't yet) please verify that writing/reading params is OK?

(And yes, something as seemingly simple as changing # of waypoints CAN affect the structure alignment and potentially lead to other problems. I've spent hours and days chasing down alignment issues -- the last time because I changed a struct member from 8b int to 16b w/out thinking much of it, then several days later discovered the issue and had to backtrack until I figured out what caused it... PITA.)

Cheers,
-Max

[Max]

[wangyeee]

[wangyeee]

[Max]

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

[wangyeee]

[Max]

[Max]

PS. Regarding formatting of params for storage, now that we can we want, they could be formatted "pretty" based on the type, instead of assuming all float values and worrying about preserving bitfields properly. The longer-term goal is to store the param values in a union (I think) and be able to retrieve the exact data type w/out casting (implicit or otherwise).

-Max

[rput]

No expert on this, but can you do something with pragma?

http://infocenter.arm.com/help/index.js ... FEEDG.html