Memory management on BCM920737

Tip / Sign in to post questions, reply, level up, and achieve exciting badges. Know more

cross mob
Anonymous
Not applicable

For some reason my application memory gets corrupted during the runtime. Some global array elements start to contain non printable characters (when it should be all printable) or some null elements start to contain non null, non printable chars. I initialise those global variables with memset setting all bytes to 0. Are there any control mechanism I could use to change the memory space used by the board for my variables? Funnily whenever I try to debug those corrupted array elements with ble_trace the problem goes away.

0 Likes
1 Solution
Anonymous
Not applicable

It looks that it was caused by

sprintf(t, "%c", isGateway ? 'G' : 'B');

I honestly do not understand why it is causing issues.  I understand that it was overkill and simpler

*t = isGateway ? 'G' : 'B';

works just fine.  It looks strange because other sprintf calls works fine, the only difference is just I am using %d specifier instead %c. Also I tried

sprintf(t, "%c", 0);

sprintf(t, "%c", 'G');

sprintf(t, "%c", 'B');

and they work fine as well.

Arduino was more sensitive on this issue and still did not work with the "fix" above which kept me going. The real issue was that sprintf() always adds additional '\0' (null) character at the end. So in the example above I was expecting one character, but it was constructing two characters 'B\0' instead. char pointer t had only space for one char, but not for two, so that additional null character was added to forbidden memory space which ended up in a mess. Surprisingly it did not complain when I was running it on my laptop and even valgrind did not complain about this at all which is really pity and makes very hard to debug these kind of issues. Is there an option on valgrind which could help to find about this sort of issue? Any other debugging tool which could help? Sorry about blaming the board. I blamed the board only because it worked perfectly fine on the laptop, but obviously this was an issue in my code.

View solution in original post

7 Replies
Anonymous
Not applicable

hello greblys

could you be more clear about the memory where you are storing those data?

is it NVRAM?

did you tried - giving values directly rather than using memset ?

Regards

Sid

0 Likes
Anonymous
Not applicable

No, it is not NVRAM. I did not specify them to store anywhere specifically so it should be using default location. I suspect that's volatile RAM.

No, I did not try to specify values without memset.

0 Likes
Anonymous
Not applicable

okay

in one of my application both memcpy and memset did not work, so i did assign direct values and it worked...

it should work if you give assign values to those variables. give it a try!!

Regards

Sid

Anonymous
Not applicable

is that still an issue ?

0 Likes
Anonymous
Not applicable

Thanks you for a suggestion. Yesterday I tried to run the same sketch on the Arduino uno and it fails similarly as Broadcom chip.  The error behaviour is different, but they both fail at similar execution flow position.  I will try to rewrite system library functions: memset, memcpy and sprintf and see if that helps as you suggested.

0 Likes
Anonymous
Not applicable

It looks that it was caused by

sprintf(t, "%c", isGateway ? 'G' : 'B');

I honestly do not understand why it is causing issues.  I understand that it was overkill and simpler

*t = isGateway ? 'G' : 'B';

works just fine.  It looks strange because other sprintf calls works fine, the only difference is just I am using %d specifier instead %c. Also I tried

sprintf(t, "%c", 0);

sprintf(t, "%c", 'G');

sprintf(t, "%c", 'B');

and they work fine as well.

Arduino was more sensitive on this issue and still did not work with the "fix" above which kept me going. The real issue was that sprintf() always adds additional '\0' (null) character at the end. So in the example above I was expecting one character, but it was constructing two characters 'B\0' instead. char pointer t had only space for one char, but not for two, so that additional null character was added to forbidden memory space which ended up in a mess. Surprisingly it did not complain when I was running it on my laptop and even valgrind did not complain about this at all which is really pity and makes very hard to debug these kind of issues. Is there an option on valgrind which could help to find about this sort of issue? Any other debugging tool which could help? Sorry about blaming the board. I blamed the board only because it worked perfectly fine on the laptop, but obviously this was an issue in my code.

Thanks for reporting your findings back to the thread Lukas.

0 Likes