- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
Solved! Go to Solution.
- Labels:
-
SDK 2.X
- Tags:
- ram memory
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
is that still an issue ?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Thanks for reporting your findings back to the thread Lukas.