• State Resolved
  • Locked Locked
  • Replies 4 replies
  • Subscribers 98 subscribers
  • Views 1297 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

Reset DSP after a crash

Joern
Genius 3055 points

At DM8148 we have a program running on ARM side, which initially loads a DSP binary, by use of the Codec Engine. The development is done by EZSDK 5.05.02 (resp. the regarding NELK-SDK variant). So far all works fine. But.

In case of crashes it may happen, that afterwards the DSP binary cannot be loaded anymore (Codec Engine error message "Can't open engine ...").

Until now in those cases we have to reboot the whole system to get our software running again.

Is there a possibility to (easily?) reset the DSP only, controlled from ARM side? Several tries to just unload the drivers (as syslink.ko) did not work ('driver still in use', sometimes system became frozen).

In a former forum entry Badri Narayanan wrote: "It is not possible to individually reset and recover from M3/c674 hang due to syslink limitation."

Is that still true? No way?

Thanks in advance,
Joern.

  • 0
    TI__Guru**** 170625 points
    Hi Joern,

    See the below e2e thread:

    e2e.ti.com/.../256582

    BR
    Pavel
  • 0 in reply to Pavel Botev
    Genius 3055 points

    Hi Pavel,

    thanks for this link - when I followed it I realized that already formerly I stumbled over. I did hope for an 'easy' solution, f.e. by just calling a CodecEngine function...

    Until now no success - if the DSP binary cannot be loaded anymore, then 'firmware_loader 0 dspbinaryname stop' never comes back - firmware_loader obviously crashes. But that seems not unexpected to me, as our DSP binary is not loaded by the firmware_loader; we use CERuntime_init, Engine_open, UNIVERSAL_create.

    Maybe it will help to dig into the firmware_loaders sources - that will be my next step.

    P.S.

    Just to mention it for other readers: if you too are missing the tool devmem2, I found it within the NELK-SDK resp. EZSDK: component-sources/graphics-sdk_4.04.00.02/tools/devmem2/Obj/devmem2.

  • 0 in reply to Joern
    TI__Guru**** 170625 points

    Joern said:
    I did hope for an 'easy' solution, f.e. by just calling a CodecEngine function...

    I have checked the CE user guide, but I can not find such function to be called.

    Regards,
    Pavel

  • 0 in reply to Pavel Botev
    Genius 3055 points
    Thanks a lot, Pavel, for this clarification.

    Regarding your former hint above it seemed a bit too complicated to me to follow that approach to power off/on the DSP for a reset - at least with respect to the time planned for this solution (rebooting works anyway).

    But the problem that after (ARM side) crashes the DSP binary could no longer be loaded seems to be solveable now by just reloading syslink, cmemk and a bunch of other involved drivers. I tried this before as well, but it did not work - I always earned a frozen system or a crash caused by... limited vmalloc resources when trying to initialize the cmem component again. And that lead me to analyze the left vmalloc ressources.

    If I reduce the memory space controlled by cmemk, then also after restarting all the drivers there is no crash at next cmem initialization. That might depend on the load order and on the allocation behaviour of other drivers, which might lead to changed situation regarding vmalloc ressources comparing loading the drivers at boot time and at a later restart, not yet clarified.

    Also I assumed that some driver might eat vmalloc memory by not correctly releasing such memory - I found one: ti81xxhdmi, but it eats only 8192 bytes at each restart, which obviously was not the whole reason for the problem. Regarding ti81xxhdmi I'll open a new thread here in the forum.

    Regards,
    Joern.