2020-12-05 08:31 AM
Hi everyone!
The best thing, sometimes, about writing to a forum is that: often describing the problem helps you to find what you were doing wrong... so this is solved. But, I thought I would add it here to keep value in the community. Say hi if it helps you.
The solution is simply to make sure that when you actually use your const data, be sure that you are referencing it with pointers, otherwise you might be copying a lot of data into SRAM.
[ the original issue and observations ]
I need to have about 150k of data in flash. (sizeof(myData )=149456).
But my stack size is like 1k on the RTOS task.
The data is in its own C file as a static const with structs and arrays of structs, etc.
It's a generated file that is all values and no pointers to other places.
static const myData_t myData = { .someArrayOfStructs = { } , .ArrayOfOtherArrayOfStructs = {} }.
Then I get the whole thing via a pointer with:
myData_t * MYDATA_get_pointer() { return &myData; }
In this way I can get the data to my other libraries and work with it.
When I test my code on a reduced dataset (sizeof(myData ) = 3456), everything runs fine.
However, when I scale up, I suspect what is happening is that I'm overloading the stack size of the RTOS task and hitting the hardfault handler - Often some time later, in another RTOS task - probably because overloading SRAM here writing to places where is shouldn't be. I'm surprised if that is even possible in RTOS.
WHY was this happening for me? ... it was so simple and obvious, when you think about it.
I had the data saved correctly as a static const correctly. But, when i work with it I was copying it
ie:
foo_t foo = myData->myFoo[10];
And it turns out that myFoo[10] still has a good 10k of data in it.
But, the complier doesn't complain about this. (why?.. it would be nice, no?)
The fix is just do keep foo as a pointer
foo_t * foo = &(myData->myFoo[10]);
THEN the compiler warns "initialization discards 'const' qualifier from pointer target type".
So finally:
const foo_t * foo = &(myData->myFoo[10]);
Solved! Go to Solution.
2020-12-07 05:56 AM
solved. as above
2020-12-07 05:56 AM
solved. as above