Hi guys,
in the TI forums there are a few threads about a strange issue debugging McfW/OpenMax applications with DM81xx systems.
Here an update, hoping that this post will draw more attention than the previous ones.
If you have some further information, fell free to integrate these notes, please
People observed that:
- it is not possible to debug the application with gdb/gdbserver because applications theirself don't stop (on a breakpoint, on a signal...)
- if an application crashes (because of a SEGV, for example), it doesn't "die" but remains in D state (uninterruptable state) and use 100% of the CPU and you aren't able to "kill" it. I know that we all are very good programmers and that the code that we write is bug-free, but in the real world applications sometimes _do_ crash and (especially in an embedded system) it is vital to be able to restart them (via monit, for example). Now, after a SEGV, you have to reboot manually the machine.
The real problem seem to be a wrong signal management in syslink/kernel code, as pointed out by Joel Keller (see http://e2e.ti.com/support/dsp/davinci_digital_media_processors/f/716/t/162491.aspx#596515).
That behaviour has been seen with both McfW and OpenMax applications
Neither RDK Release Notes nor Ezsdk ones highlight that problem in their "Known Issue" section.
This issue has been raised from several months but the only "official" response by TI guys has been the one from Siddharth Heroor (see http://e2e.ti.com/support/dsp/davinci_digital_media_processors/f/716/t/162491.aspx#595910). Is there any update? Something like "We __DO__ spent our time working on that and we hope to release a bugfix next week/month/year" would be very appreciate, at least.
Related to this issue, there is the question of which toolchain to use.
Both RDK and EZSdk documents state that the software has been validated with 2009q1-203 toolchain. Lee Holeva pointed out (see http://e2e.ti.com/support/dsp/davinci_digital_media_processors/f/717/t/160644.aspx#584398 ) that gdb and gdbserver on that version are broken of their own and that we should switch to a newer release. In the light of that consideration, is the 2009q1-203 one the best/preferred toolchain to use? I do understand that validate an entire sdk with a different toolchain is a huge task, but I hope that you understand as well that having a working debugging support is critical.
If it may help, I volunteer to do any debug, to try any patches or to do any tests that may lead to a quicker solution.
Thanks in advance
Ivan
