DSP Firmware exit function(s) when stopped by firmware_loader

Jose Lopez1 said:

I am looking for something similar as the xdc.runtime.Startup module that offers

Startup_firstFxns

Startup_lastFxns etc ..

Jose,

There is no "shutdown" or "exit" counterpart to the xdc.runtime.Startup module, so you will need to manually construct a scheme to achieve your goal.

What version of SysLink are you using?

I ask because the later versions of SysLink have an API named Ipc_detach() that becomes a "sync" or "rendevous" point between the host ARM and slave DSP.  This sync point would allow the application to know that the DSP has completed necessary shutdown activities.  Without such a sync point, there's no easy way to know that the DSP has completed its shutdown activities before "pulling the plug" on the DSP (by "pulling the plug", I'm referring to the fact that SysLink, under control of the firmware_loader, will shut down clocks to the DSP, thereby ending the DSP execution).

Related but separate to the Ipc_detach(), the DSP needs to be told to shutdown, which is the manual scheme I mention above.  A good way to achieve that instruction to the DSP is through the Notify mechanism.  The DSP can register for a Notify event with the
    Notify_registerEvent()
API, and when that event's callback is invoked the DSP can perform its shutdown activities.  The host ARM application will need to send the event for which the DSP registered, through the
    Notify_sendEvent()
API.  In this case, the host ARM application is firmware_loader, and you will want to modify firmware_loader to do this.  firmware_loader calls ProcMgr_stop() at some point, which is where the DSP's plug is pulled, so you need to do all this before ProcMgr_stop() is called.

Regarding the sync point offered by Ipc_detach()...

If firmware_loader sends the "shutdown DSP" Notify event and then simply calls ProcMgr_stop(), the DSP will probably not have had the time to perform its shutdown activities before its power is cut.  With Ipc_detach(), each side (DSP and ARM) calls that API, so when the DSP is done with its shutdown activities it can call Ipc_detach() as its last action.  The firmware_loader will also call Ipc_detach() immediately before calling ProcMgr_stop().

Without this sync point native to Ipc, I would suggest that you create a handshaking scheme:
    - ARM registers for Notify event representing the DSP "Ack"
    - DSP registers for Notify event representing "you're being shutdown"
    - ARM sends "you're being shutdown" event to DSP
    - DSP responds to this event (via event callback) by performing its shutdown activities
    - DSP sends "Ack" event to ARM
    - ARM responds to this event (via event callback) by calling ProcMgr_stop()

Having typed all this, it feels like a lot to do, but I don't think it would be too hard.

Regards,

- Rob

Robert,

I am working with ezsdk-5_05_01_04/  and syslink_2_20_00_14, I think I should have Ipc_detach on this version. 

From your reply, I should use Notify API on both sides, does this Notify module works for both processors?

So, if I do

#include <ti/ipc/Notify.h>

it works for Linux and BIOS code?

I say so because I saw content like: syslink/packages/ . . ./ipc/hlos/usr/Linux/NotifyDrvUsr.c

I presume that  when used this Notify API i should be able to set my callback fxns on DSP and ARM sides.

Thanks

Rob, 

Thanks for your clear explanation, I may need to implement something like that soon, so some maintanance tasks that run at background do not finish abruptly.

I may say as a suggestion, that it would be nice that TI experts offers in the future an API like "ti.sysbios.Closeup" (just came to may mind), so programmers can use some standard Firmware unloading routines and could prevent runtime misbehaviors of the SoC due to unloading when the Firmware is not ready, dont know if it could be useful, depends on each implementation.

Thanks again,

Regards