hotz
New Member
Posts: 28 
|
Post by hotz on May 4, 2017 17:25:21 GMT
I have run into an issue where the ShieldBuddy freezes after running for around 3 hours.
This has been consistently happening for over a week now.
At first I thought I might be running low on memory, but I have moved about half of the code from the most full core to a core that was using hardly any memory.
That did not resolve the issue.
Has anyone noticed any similar problems or memory leaks?
At one time when I was outputting a lot of SerialASC.print data I was getting freezes after running just a few minutes, but then the Shieldbuddy team increased the SerialASC.print buffer and it seemed to cure that problem
Is it possible that it is somehow related to that or that some other buffer is getting filled up?
Other than the Freeze at 3 hours the Shieldbuddy has been working great!
Any ideas on what might be causing this would be greatly appreciated.
While we are discussing memory... What would be the best way to see the memory status in real-time?
I am doing the development in the Arduino Environment.
Thank you in advance for any and all help.
|
|
|
|
Post by Admin on May 4, 2017 17:54:48 GMT
Hi,
How many interrupts have you got running? Are you using the create timer functions?
Is it possible to roll back the software to a point where it works ok?
If a program hangs it is usually because a trap has occurred. At the moment the trap status and cause is not visible in the Arduino IDE but we are thinking of changing this.
It might be that your application is too big and complex for the Arduino IDE. You may need to use the Eclipse IDE with the debugger. This would allow you do a "post mortem" and see what has happened. It also allows variables to be monitored in real time.
You have all the tools already installed.
|
|
|
|
Post by Admin on May 4, 2017 19:37:57 GMT
Please can you send me the .map file for the program. This will be in an automatically created directory something like:
"C:\Users\MBEACH~2.HIT\AppData\Local\Temp\arduino_build_262414/PWM_Measure.ino.map"
This file will show how much RAM is being used. It may be that your program has overflowed the context save area under certain conditions. You can increase the size of this in the iROM.ld file, located in "C:\Program Files (x86)\Arduino\hardware\aurduino_Dx\aurix\variants\tc275\linker_scripts\gcc":
/*
* Define the sizes of the user and system stacks.
*/
CORE_SYM(_ISTACK_SIZE) = DEFINED (CORE_SYM(_ISTACK_SIZE)) ? CORE_SYM(_ISTACK_SIZE) : 1K;
CORE_SYM(_USTACK_SIZE) = DEFINED (CORE_SYM(_USTACK_SIZE)) ? CORE_SYM(_USTACK_SIZE) : 12K;
CORE_SYM(__CSA_SIZE) = DEFINED (CORE_SYM(__CSA_SIZE)) ? CORE_SYM(__CSA_SIZE) : 2K;
This repeats 3 times, one for each core. You could try increasing the 2K to 3K and see if it makes any difference.
|
|
hotz
New Member
Posts: 28
|
Post by hotz on May 9, 2017 11:50:17 GMT
I implemented the 2K to 3K change and have been running some tests, which have taken a long time due to the nature of how long it takes to see the problem.
So far it has changed the time to the Freeze from around 3 hours, to around 7 hours. But at 7 hours or so, I still get a Freeze.
What is the Maximum size I should experiment with?
Do my finding above seem to indicate a Memory Leak?
I can send you the "PWM_Measure.ino.map" but I am in the middle of running some other tests as well.
As an additional test, I have moved all of the code back to a single Core to see if it would run at all and also to compare it's performance to an Arduino Due, with the same code.
Interestingly it has no problem running on a single core and the Freeze occurs at the same general time frame as when it is running on multi-cores.
Currently, the timing difference between running on multi-cores and a single core is only about 0.2 to 0.3 milliseconds.
|
|
|
|
Post by Admin on May 9, 2017 12:01:18 GMT
There is not much scope for memory leaks with the ShieldBuddy as it only uses malloc() in the EEPROM emulation functions. It is interesting that the freeze time is now 7 hours after increasing the CSA_SIZE to 3k. The CSA (context save area) is used instead of a conventional stack and each function entry or interrupt entry will cause additional CSA memory to be used. The map file would give some idea how deeply nested the functions are and how much RAM we have left for the CSA, USTACK and ISTACK. The default settings we have used are for typical Arduino-style programs but your app is a big one! You could try these settings:
/*
* Define the sizes of the user and system stacks.
*/
CORE_SYM(_ISTACK_SIZE) = DEFINED (CORE_SYM(_ISTACK_SIZE)) ? CORE_SYM(_ISTACK_SIZE) : 2K;
CORE_SYM(_USTACK_SIZE) = DEFINED (CORE_SYM(_USTACK_SIZE)) ? CORE_SYM(_USTACK_SIZE) : 12K;
CORE_SYM(__CSA_SIZE) = DEFINED (CORE_SYM(__CSA_SIZE)) ? CORE_SYM(__CSA_SIZE) : 4K;
You could keep increasing these ultimately until you get a linker address space overflow error!
We are thinking of adding some functions into the ShieldBuddy add-in to report how much free RAM there really is.
|
|
