DSP BIOS HWI w dispatcher not working?

Alex,

Nothing obvious jumps to mind.  Can you please post the HWI-related configuration snippets from your TCF?  Also, details of any HWI calls you are making at runtime?  This will help to narrow the problem…

Thanks,
Scott

Hi Scott,

I have similar issue. Using F28335 starter kit wih CCS version 5.1 and BIOS version 5.41.11.38.

I have around 8 interrupts for communication and one for timer. Apart from the timer interrupt none of the other interrupts are being handled.

Regards,

Sangeetha

Sangeetha,

Can you please do the same as I’d asked Alex?  Post the HWI-related configuration snippets from your TCF, and details of any HWI calls you are making at runtime?

I didn’t get any info from Alex, and don’t know if he is still seeing an issue.

Scott

 Hello!

 Sorry for not answering. I have been busy with other things.

 The fact is that I have done an step forward in the program, tough it still doesn't work well. I have managed to configure the interrupts so they are called correctly. One of the problems was that my UART interrupt routine (UARTRx_HWI and UARTTx_HWI) receives a parameter telling which UART has interrupted, which was configured in the configuration tool. That didn't worked. Instead I created 6 HWI functions, which called the generic UARTRx_HWI and UARTTx_HWI with the correct parameter, and it succeded. Here is now the code of the tcf:

bios.PIE.instance("PIE_INT9_1").fxn = prog.extern("UARTA_RxHWI");
bios.PIE.instance("PIE_INT9_1").useDispatcher = 1;
bios.PIE.instance("PIE_INT9_2").fxn = prog.extern("UARTA_TxHWI");
bios.PIE.instance("PIE_INT9_2").useDispatcher = 1;
bios.PIE.instance("PIE_INT9_3").fxn = prog.extern("UARTB_RxHWI");
bios.PIE.instance("PIE_INT9_3").useDispatcher = 1;
bios.PIE.instance("PIE_INT9_4").fxn = prog.extern("UARTB_TxHWI");
bios.PIE.instance("PIE_INT9_4").useDispatcher = 1;
bios.PIE.instance("PIE_INT8_5").fxn = prog.extern("UARTC_RxHWI");
bios.PIE.instance("PIE_INT8_5").useDispatcher = 1;
bios.PIE.instance("PIE_INT8_6").fxn = prog.extern("UARTC_TxHWI");
bios.PIE.instance("PIE_INT8_6").useDispatcher = 1;
bios.PIE.instance("PIE_INT1_6").fxn = prog.extern("adc_HWI");
bios.PIE.instance("PIE_INT1_6").useDispatcher = 1;
bios.PIE.instance("PIE_INT8_1").fxn = prog.extern("I2C_HWI");
bios.PIE.instance("PIE_INT8_1").useDispatcher = 1;

Now... the problem is that altough I am transmitting and receiveing data, I get data corruption, and the system hangs in a minute or so. I have not had time to debug properly, but I hoped that the thread configuration didn't needed to be changed when executing the HWI with dispatcher.

I am not calling other HWIs apart from the shown, and only one periodic interrupt every 20ms.

aLeX

Alex,

Thanks for the snippets. 

When you were trying to pass an argument to the ISR function via the dispatcher, were you following a format such as this:

    bios.PIE.instance("PIE_INT9_1").arg = 1;

And you modified the ISR function signature (from the interrupt keyworded case) to accept the argument, and weren’t getting it when the ISR ran?  You said earlier “and removed "interrupt" keyword from the interrupt function. I think that's all I have to do to change it”.  I just want to make sure you also added the argument to the ISR signature.

For the corruption after a while failure cases, I wonder if you need additional masking of interrupts by the dispatcher.  Since you have many serial interrupts (and 6 sources just from the UART), I wonder if the program or some of the ISRs are vulnerable to preemption during an ISR.  When you enable the dispatcher, the default masking option is to only mask the interrupt that is being serviced, and allow other interrupts to preempt.  As an experiment, I wonder if the corruption goes away if you mask more interrupts during each ISR.  For example:

    bios.PIE.instance("PIE_INT9_1").interruptMask0 = “all”;
   …

Do you think that might be necessary for your application?

Scott

 Hello,

 When I tried to pass the argument, I added the argument to the function, yes, but I don't know if I really added the RIGHT argument, as I have not found any place saying what type it has to be. I tried with integer and with char, both without results.

 I have changed the interruptmask to "all", and nothing changes. One thing that I have to say is that the software doesn't crash, but the data received in the UART RX interrupt is somehow incorrect. I don't know why, because if I mask all the interrupts it should behave like in the "no dispatcher" mode, isn't it?

 Alex

 Hello,

 After a while working in the overall system, now I've had time to debug this part of the system and I've found some strange things:

 Now I can use the interrupts with the dispatcher, but when I signal semaphores in the interrupt, it does not work correctly. Doing some tests, I have found that, with or without the dispatcher, if my HWI spends more than 5us in it, RX data from the UART (or the buffers) is corrupted, or sometimes the overall system is misbehaving.

 I have measured the duration of the WHI with a GPIO pin, and I have tested it with different delays inside the HWI (for loops doing nothing). If I set a 5 iteration loop, everything works fine, but if I set it to 15, for example, data received into the buffer is not correct. the HWI passes from 3us to 5us, and I don't receive correct data. The next HWI occurs 100us later, so the HWI have plenty of time to get the data from the UART and place it correctly in the buffer.

 I know I have to keep HWI as short as possible, but I think 5us is pretty short. The main problem comes when I do a SEM_ipost, which is a system function. Anyway... long HWI should cause the system to behave slower, but not receive incorrect data...

 Any clues? This misbehaviour es driving me mad.

 Alex

Alex,

A couple of things ...

Alex Bueno said:

but when I signal semaphores in the interrupt, it does not work correctly.

The SEM_post() function has the following constraint.  Can you make sure that you're doing this(from the DSP/BIOS API Guide...)?

When called within an HWI, the code sequence calling SEM_post
must be either wrapped within an HWI_enter/HWI_exit pair or
invoked by the HWI dispatcher.

Alex Bueno said:

I have tested it with different delays inside the HWI (for loops doing nothing)

What kind of for loop are you adding I wonder?  Is it just an empty loop?  The compiler may be optimizing the loop out completely.  You may want to do something like:

volatile int x = 0;

for ( <your delay>) {

    x++;

}

Declaring x as 'volatile' will tell the compiler not to optimize it out.

Steve

 I am signaling SEM_ipost from the HWI, and the HWI is working from the dispatcher. The fact is that the semaphore works fine, but the data received is corrupted, I don't know why.

 The for loop is working correctly, because when I increment the loop, I see the HWI increase its duration (with a GPIO pin I'm monitoring). What I was trying to explain is, that having a working HWI, reception correct, and a loop of 3, if I increment this loop to 10, for example, my data is not received correctly. Why increasing a bit the HWI makes the system not usable? The overall duration of the HWI is very low, so all the other threads have plenty of time to execute, and I don't know what is the problem with the HWI.

 By the moment I can receive correctly reduciong the HWI duration at minimum, but I have disabled the dispatcher of the HWI and the semaphores, because if I enable any of these, the errors come again (as the duration of the HWI is bigger with dispatcher and more with the sempahores)

  Any clues?

  aLeX

Hi Alex,

From a previous post you said:

Alex Bueno said:

the HWI passes from 3us to 5us, and I don't receive correct data.

I'm wondering if you are simply spending too much time within your HWI ISR, thus causing you to miss an interrupt (which may be providing you with the data you are missing).  When an HWI is being serviced, interrupts are disabled.

According to the DSP/BIOS User's Guide, there is a real-time threshold for HWIs that is just around 5us.  Maybe in your system this is just cutting it too close.

Have you tried moving the code you have in your HWI ISR into a SWI function, and then posting the SWI from within the HWI ISR?  This would allow other interrupts to run since interrupts would be re-enabled for the SWI function run.

Here's a snippet from the DSP/BIOS User's Guide that I saw. I bolded the part I'm referring to above:

Here are some rules for deciding which type of object to use for each task to
be performed by a program:
❏ SWI or TSK versus HWI. Perform only critical processing within
hardware interrupt service routines. HWIs should be considered for
processing hardware interrupts (IRQs) with deadlines down to the
5-microsecond range, especially when data may be overwritten if the
deadline is not met. Software interrupts or tasks should be considered for
events with longer deadlines—around 100 microseconds or more. Your
HWI functions should post software interrupts or tasks to perform lowerpriority
processing. Using lower-priority threads minimizes the length of
time interrupts are disabled (interrupt latency), allowing other hardware
interrupts to occur.

Steve

 I have checked that the data is not lost, even when the HWI lasts more than 5us: the OverrunError bit in the UART is never set. I have set a GPIO to show when I enter that HWI and when I exit from it, and looking at it I can see the HWI entering and exiting correctly when I receive every character. Also I receive one character every 50us, so it should be no problem having a HWI of 10us, isn't it? Unless there are other DSP/BIOS restrictions that affect stack or data and I don't know which are.

 I have thought about calling a SWI from a HWI but... if I am loosing characters, don't you think that posting a SWI to make the job the HWI is doing will be slower than doing it in the HWI directly, thus loosing more data? And this is the only HWI that is executing, so it should be no problem that this HWI lasts too much, isn't it?

 I will try to post a SWI from the HWI, but I don't know if this will improve the system, because as I said, I don't have any overrun errors in the UART, I only see that the data received is not correct...

 aLeX

Hi Alex,

Just wondering if you were able to try moving your HWI code into a SWI, and posting the SWI from the HWI?

Alex Bueno said:

And this is the only HWI that is executing, so it should be no problem that this HWI lasts too much, isn't it?

But you do have other HWIs in your application right?  In a previous post, didn't you show that you had 6 HWIs just for UART alone? It sounds like there is a lot happening in your application, so I think it is still important to keep the HWI time minimal.

Steve

 6 HWI are 2HWI x 3 UARTs:

 - One of the UARTs is for a LCD screen. Transmit, and no receive. And "usually" the screen is always the same, so the issue is not with this 2 HWI

 - The other UART is a second channel UART, which usually doesn't receive anything because at this test stage, nothing is connected. It only sends 10 bytes every 20 ms, so if we calculate that the HWI lasts 5 us (which make it fail) the CPU usage of this HWI is 0,25%.

 - The UART that is "failing". Is a half-duplex UART, when it is transferring, it is not receiving (we change a GPIO to change it externally). So we could say that th RX UART HWI is working almost "alone".

 Otherwise... if it was the case that our system had many HWI lasting so long... what? We should see overrun errors in the UART registers, or looking at the GPIO I configured when the HWI was asserted, I should see that the HWI doesn't happens when I receive a character, but THIS IS NOT THE CASE. I receive all the data, I don't have ANY overrun errors in the UART, but when the HWI lasts a bit longer than it does now, my data is somehow corrupted, or it seems so, because I stop receiving correct data in my upper thread.

 this doesn't make any sense, and I don't know what to test to know what is happening exactly...

  aLeX

Hi Alex,

Just wondering if you were able to try moving your HWI code into a SWI, and posting the SWI from the HWI?  Did this make any difference?

Steve