DSP BIOS 5.40.02.22 - Question about getting two interrupts\tasks to coexist .

Hi Andrew,

Firstly, thanks for the reply - the really useful bit was the comment about running the task in a while() loop - I wasn't doing that, so with my HDLC_Rx_Tsk  read task encapsulated in a while loop, it does get called every time, so that's good progress.

I stripped the project down to a "minimal criminal" project build that had just  the /INT1 interrupt and the TSK that responds to the message post made in INT1's interrupt service routine, and found by observing it (INT1) on the scope that the interrupt frequency was far from regular - in fact it was almost random, varying from being every 80 uS up to every 30uS - plus there was no guarantee that reading the data FIFO over the SPI would actually clear the interrupt signal. The reason for this was that the RF tranceiver wasn't receiving a valid signal, and so was not in a deterministic state as far as interrupts were concerned - but with a valid signal, things settled down and  a regular 80uS interrupt was generated and serviced OK. Again, more progress :-)

There's one issue that I haven't got to the bottom of yet - if I drop the 'interrupt' keyword from the ISR source code, and then in the Configuration Tool GUI configure the HWI object associated with /INT1 to use the BIOS interrupt dispatcher, then the interrupt will run just twice. On the second time through the ISR,  the debugger halts in a routine called HWI_F_dispatch, and after a few run - halt cycles, I eventually get an error message " Can't Run Target CPU..... Processor communication timeout, .....Power Cycle the target board before continuing".

I assume that the  HWI_F_dispatch function is part of the BIOS dispatcher code. I don't know why the code halts here, unless there's some sort of exception handling being invoked  ??

The code runs OK when I don't use the BIOS dispatcher, but it would be more desirable to use the BIOS, for consistency.

I'm confused as to what is the recommended approach - the BIOS User Guide (document reference SPRU423h) states in section 4.2  (Hardware Interrrupts), that " To allow an HWI objects function to be written completely in C, the system HWI dispatcher should be used".  In the C/C++ Compiler User Guide (document reference SPRU281F), section 6.6.3 (Using C/C++ Interrupt Routines ), it states that the interrupts can be handled directly using  the 'interrupt' keyword  - and at the minute that seems to the only method that works for me.

Presummably the 'interrupt' keyword allows the compiler to add what ever code is necessary for the context switch - similar to the HWI_enter and HWI_exitcode in the BIOS dispatcher   ???

Below is my code...

interrupt void AX5042_Rx_Isr(void)
{

  uint16_t temp;
  MsgObj1 HDLC_msg;
// must read the AX5042 FIFO to de-assert this interrupt pin.

        
        g_count++; // increment global count to check how often the ISR is hit.
        MBX_post (&MBX1, &HDLC_msg, 0);
        //AxSpiRead(AX5042_REG_FIFODATA,0x00);
        temp = IFR0;
        //temp &=0xFFF7;  //disable any further INT1 interrupts until this one is serviced by the associated task.
           IFR0 = temp; //clear /INT1 interrupt ??  - does the CPU not do this for you ?

}

. and here is the Task that processes the Mailbox post made in the ISR..

#include "stdint.h"
#include "stdint.h"
#include <bios.h>
#include <mbx.h>
#include "appData.h"
#include "spi5042.h"
#include "register_cpu.h"


extern MBX_Obj MBX1;

void HDLC_Rx_Tsk(void)
    {
        MsgObj1 msg1;  // dummy message for now.
        uint16_t temp;
        Bool status;
       
        while(1){
        status = MBX_pend(&MBX1,&msg1,10); // wait one system clock tick before returning. (was 0).
       
        if (status != 0)  // i.e., return value from MBX_pend is true
            {
              temp = AxSpiRead(AX5042_REG_FIFOCONTROL,0x00);
              AxSpiRead(AX5042_REG_FIFODATA,0x00);
                  //temp = IFR0;
                //temp |=0x0008;  //enable  further INT1 interrupts since this one is serviced
                   //IFR0 = temp; //enable /INT1 interrupt ?
              //AxSpiRead(AX5042_REG_FIFODATA,0x00);
              //AxSpiRead(AX5042_REG_FIFODATA,0x00);
              //temp = (Uint8)(AxSpiRead(AX5042_REG_IRQREQUEST,0x00)& 0x00FF);
             
            }
        }   
    } 

 Once again, thanks for your help and posting the example code - much appreciated !!

Best regards

Michael

You should only call MBX_post when using the BIOS dispatcher.  Otherwise BIOS will not realize that a hardware interrupt has occurred and it could inadvertently perform a context switch thinking it was still in some other task.  Your procedure of enabling the dispatcher and removing the interrupt keyword was the correct thing to do.  I'm scratching my head a bit at what could be the issue.  One other thing you might try is in the BIOS HWI settings to set the interrupt mask as "all".  That will mask all interrupts during the ISR such that your ISR cannot be pre-empted.  I don't know why that would be causing an issue, but it would make it behave more like your case where you use the interrupt keyword.

Suggestions to consider and try:

One thing that confused me initially with DSP/BIOS was that you had to exit main() - not clear from your previous posts if you are definitely doing this.  I think you must be to have got as far as you have - but just in case....

To help debug things try simplifying your TSKs by removing MBX code.

Consider switching your functions from TSKs to SWIs - a relatively easy thing to try and conceptually closer to traditional interrupt driven code.  In particular changing your highest priority function to SWI will guarantee it prempts the TSK because SWIs are higher priority than TSKs

Regards, Andrew

Hi Andrew,

I am exiting from main() OK - I think we have got to the bottom of the dispatcher issue too - I hadn't deleted the 'interrupt'  qualifier in the header file where the isr function was declared.

The /INT1 Task now runs OK, and the DMA Task also runs OK, both using the dispatcher, so I will now try and get them to run together - if that doesn't work, I'll definitely try the SWI approach that you suggest for /INT1, as it is of high enough priority to warrant such an method, especially if I need to increase the bitrate of the link at some point in the future.

Once again, thanks for your help, it has been very useful !

Cheers

Michael.

Michael Feerick said:

One thing I noticed in the Configuration tool GUI was that  when I tried to reverse the setting for IER1 back from 'all' to ‘self’ that the Configuration tool would freeze, requiring it to be shut down. This was consistently repeatable, and if I try to change IER1 to anything other than ‘all’, it also results in a program hang - is that a known issue ?  The version of the Configuration Tool is 5.00. I can verify that it is set to 'all' by looking at the resultant *.cdb file.

Strange one.  Instead you can simply open up the tcf file in a text editor to delete the line that was added to make that change to begin with.  However, I would recommend that you set ALL of your interrupts to mask "all" unless for some reason you really want/need pre-emption.  As long as you're keeping your ISRs concise there's not generally a need for pre-emption of interrupts.  Furthermore it will result in greater stack requirements since each interrupt will cause the stack to go deeper potentially overflowing it.

H Michael,

Could you communicate using AX5042 chips?

Thank you.

Michael Feerick said:

plus there was no guarantee that reading the data FIFO over the SPI would actually clear the interrupt signal. The reason for this was that the RF tranceiver wasn't receiving a valid signal, and so was not in a deterministic state as far as interrupts were concerned - but with a valid signal, things settled down and  a regular 80uS interrupt was generated and serviced OK.

Hi Michael,

Sorry to bother you but I am having a similar issue with the AX5042. I'm in a perpetual interrupt state because the AX5042 FIFO always has random content in the buffer thus triggering the interrupt. I empty the FIFO by reading this content and this clears the interrupt but then the interrupt is immediately triggered again with the same random garbage 0xF0, 0x90, 0xC0 ... You talk about a deterministic state and a valid RF signal, could you please elaborate. I'm new to working with RF chips and I'm not sure where this "noise" might be coming from? Any help/suggestion would be greatly appreciated.

Kind Regards,

Jaco