• Locked Locked
  • Replies 6 replies
  • Subscribers 99 subscribers
  • Views 807 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.

DSP/BIOS 5.33 Hardware Interruption context issues

armando3047
Intellectual 470 points

Hi,

I'm facing a unexpected behaviour regarding a function called from an Hardware Interruption routine, this is the situation:

1.  I am processing an event through an HWI, then form this HWI I call an function:

HWI_Fxn() {
. . .
myFxn();
}

2. From this function I post a SWI, and I added a printf:

myFxn () {
. . .
SWI_post(mySWI);
printf("HWI context\n");
}

3. In the SWI function I also put a printf:

SWI_Fxn() {
printf("SWI context\n");
. . .
}

I used to think that myFxn() runs in HWI context, this means that it runs to completion, thus, myFxn() will schedule the SWI and print; and when myFxn finishes its execution the SWI could be executed.

But I'm getting the prints in the following order:

SWI context
HWI context

Is the myFxn() function really running in a Hardware Interruption context?
If yes, why the SWI is executed before the HWI finishes?
Is this a scheduling issue on the DSP/BIOS or this behavior is expected?

Thanks and best regards.
Armando.

  • TI__Mastermind 41665 points

    My impression is that you should see the HWI message first based on section 4.3.4 of SPRU303b quoted below.

    SPRU303b said:
    When an SWI object is posted, the SWI manager adds it to a list of posted software interrupts that are pending execution. Then the SWI manager checks whether software interrupts are currently enabled. If they are not, as is the case inside an HWI function, the SWI manager returns control to the current thread.

    However, one thing to note is that you should not call printf() from a HWI or SWI context, as it ends up the LCK module which can cause problems when the TSK scheduler is disabled. I am not sure if this is what is causing your call inversion, but it is something you should be weary of.

    I will be moving this thread over to the BIOS forum for further insight.

     

  • in reply to Bernie Thompson TI
    TI__Mastermind 18320 points

    What version of BIOS are you using?

    What chip/platform are you running on?

  • in reply to David Friedland
    Intellectual 470 points

    DSP/BIOS version: 5.33.04

    running in C64+ on OMAP3430

    Regards,

    Armando.

  • in reply to armando3047
    TI__Mastermind 18320 points

    DSP/BIOS provides HWI_enter and HWI_exit routines that allow the HWI function to properly save and restore registers and therefore save the interrupted context.  In addition, these routines ensure that the SWI and TSK schedulers are called at the appropriate times and disable/restore individual interrupts while the ISR executes.

    In order to support interrupt routines written in C, DSP/BIOS provides an "HWI dispatcher" that plugs in these enter and exit macros for an interrupt routine.  Are you enabling the dispatcher in your BIOS app's configuration?

    Also, note that the interrupt keyword or INTERRUPT pragma must not be used when HWI objects are used in conjunction with C functions. The HWI_enter/HWI_exit macros and the HWI dispatcher contain this functionality.

  • in reply to David Friedland
    Intellectual 470 points

    Hi,

    Yes the dispatcher is enabled:

    prog.module("HWI").instance("HWI_INTX").fxn = prog.extern("HWI_Fxn");
    prog.module("HWI").instance("HWI_INTX").interruptSelectNumber = xx;

    prog.module("HWI").instance("HWI_INTX").useDispatcher = true;

    Thanks,

    Armando.

  • in reply to armando3047
    TI__Mastermind 18320 points

    That's strange.  I consulted with a couple of BIOS experts, but didn't come up with any really good ideas on what's going on.  The behavior you are describing is classic for the dispatcher not working. 

    I'm not sure if or how calling printf() could show strange behavior, but you may want to replace this with LOG_printf() or just breakpoints in order to confirm what's going on.  printf() is typically an expensive routine and really not suited for interrupt processing threads anyway.