swi runs before posted

david genge

Other Parts Discussed in Thread: TM4C123GH6PM

Context: CCS Version: 6.0.1.00040 TI-RTOS for TivaC: 2.10.1.38 Development board: EK-TM4C123GXL

Hello again,

Building on the SDCARD demo program:

Using XGCONF: set a clock object with an initial timeout of 10 seconds and a frequency of 1 hz to run functionX at timeout.

functionX triggers an AtoD conversion that upon completion triggers an interrupt to run AtoD_ISR.

AtoD_ISR saves the digitized FIFO contents to an array variable then posts a swiConvertAnalogValuesFxn to process the array.

swiConvertAnalogValuesFxn prints a string to the console whenever it runs so i can seen when it runs.

Here is the console output as the system starts...

    Robert Robot
       by
   Garden Robot Design

Initializing...
    UART1 - RF200
    UART5 - Pixy
    ADC
    Quadrature
    Overheat
    PWM
    Direction
BIOS_start();

swiConvertAnalogValuesFxn L:0 R:0Drive 0 is mounted <---------------- Why is swiConvertAnalogValuesFxn running here?
Using existing copy of "fat:0:input.txt"
Starting file copy
File "fat:0:input.txt" (576 B) copied to "fat:0:output.txt" (Wrote 0 B)
Drive 0 unmounted

swiConvertAnalogValuesFxn L:0 R:0                           <------------ 10 seconds has passed and the output begins as expected
swiConvertAnalogValuesFxn L:0 R:0                            <-------------1 second passes
swiConvertAnalogValuesFxn L:0 R:0                            <-------------1 second passes
swiConvertAnalogValuesFxn L:0 R:0                            <-------------1 second passes etc.

My question is: Why is swiConvertAnalogValuesFxn running before AtoD_ISR posts to swiProcessAnalogValues?

Cheers,

Dave

over 10 years ago

0 Ashish Kapania over 10 years ago

TI__Mastermind 21645 points

Hi Dave,

Can you try putting a breakpoint in the ISR & swiConvertAnalogValuesFxn and see which breakpoint is hit first ? Also, is AtoD_ISR a regular Hwi or a zero-latency Hwi ?

Best,
Ashish

0 david genge over 10 years ago in reply to Ashish Kapania

Intellectual 600 points

Thanks Ashish,

As you suggested I put a breakpoint in the ADC_FIFO_Full_ISR & in swiConvertAnalogValuesFxn.
The ADC_FIFO_Full_ISR runs first.

I commented out "ADCProcessorTrigger(ADC0_BASE, 0);" in the clock ISR routine
BUT the ADC_FIFO_Full_ISR routine STILL runs! and stops at the breakpoint.
How can an ISR execute when there is no interrupt?
Can an irq flag persist from one debug run to the next?

In case that's true
I'm going to try specifically disabling "ADC0 Sequence 0" interrupt (30) before BIOS_start();
and let u know results.
Ah Ha! As it turns out: my ADC initialization routine was enabling ADC interrupts like this:
ADCIntEnable(ADC0_BASE, 0);
IntEnable(INT_ADC0SS0);
when i commented out...
ADCIntEnable(ADC0_BASE, 0);
// IntEnable(INT_ADC0SS0);
the desired/expected behavior ensued. whew!

About "regular Hwi and zero-latency Hwi" I did not know there were two types of interrupt.
If you point me at the info i will look it up.

I appreciate your help,
Cheers,
Dave

0 david genge over 10 years ago in reply to david genge

Intellectual 600 points

About "regular Hwi and zero-latency Hwi":
Is this correct?:
The hardware responds to any enabled interrupt in exactly the same amount of time but when using RTOS the interrupts are mediated by the Scheduler (software) which can be adjusted to give any particular interrupt a 'zero-latency' response.

0 Ashish Kapania over 10 years ago in reply to david genge

TI__Mastermind 21645 points

Hi Dave,

david genge said:

Is this correct?:
The hardware responds to any enabled interrupt in exactly the same amount of time but when using RTOS the interrupts are mediated by the Scheduler (software) which can be adjusted to give any particular interrupt a 'zero-latency' response.

That is correct. The HW will take the same amount of time to respond irrespective of the interrupt number. SYS/BIOS has a SW interrupt dispatcher (Hwi dispatcher) that adds a few extra cycles before the user's interrupt handler is called. A zero-latency interrupt does not have an interrupt dispatcher and therefore when such an interrupt is triggered, the processor directly jumps to the user's interrupt handler.

Please note that a zero-latency interrupt's handler function should not invoke any SYS/BIOS APIs. If SYS/BIOS APIs need to be called from the interrupt handler then the interrupt should not be zero-latency type.

Best,

Ashish

0 Ashish Kapania over 10 years ago in reply to david genge

TI__Mastermind 21645 points

Hi Dave,

david genge said:
Thanks Ashish,
In case that's true
I'm going to try specifically disabling "ADC0 Sequence 0" interrupt (30) before BIOS_start();
and let u know results.
Ah Ha! As it turns out: my ADC initialization routine was enabling ADC interrupts like this:
ADCIntEnable(ADC0_BASE, 0);
IntEnable(INT_ADC0SS0);
when i commented out...
ADCIntEnable(ADC0_BASE, 0);
// IntEnable(INT_ADC0SS0);
the desired/expected behavior ensued. whew!

I am not sure what IntEnable() does but maybe it is conflicting with SYS/BIOS Hwi module initialization. Is this a starterware API ?

Best,

Ashish

0 david genge over 10 years ago in reply to Ashish Kapania

Intellectual 600 points

Hi Ashish,

My original program used the "Timer" demo program as a starting point.
Is that 'starterware'?

hw_ints.h was #included in that program. It contains macros which enable users of both TM4C123 and TM4C129 to refer to interrupt numbers BY NAME (like INT_ADC0SS0) so programmers don't have to look up or memorize the actual numbers.

For instance:
hw_ints.h defines INT_ADC0SS0 as 30 and of course when one uses XGCONF to create an interrupt object for the ADC that's the number one enters in the box...
so i think perhaps YES there must be some kind of conflict involved.
(Note: page 104 in Tiva™ TM4C123GH6PM Microcontroller DATA SHEET lists the interrupts ).

Note: in XGCONF the box labelled "Interrupt number" should be labelled "Vector number".
When will 'box' become a 'drop-down list box' containing the names of all the possible interrupts for the already elsewhere specified target processor? Bound to speed development!

Ashish which document discusses Hwi vs zero-latency Hwi, how to configure etc.?

Again thanks very much for your time and effort.
Cheers,
Dave

p.s. Good News! All of the critical code has been migrated into RTOS, tested and working in the robot. :)

0 Ashish Kapania over 10 years ago in reply to david genge

TI__Mastermind 21645 points

Hi Dave,

david genge said:

My original program used the "Timer" demo program as a starting point.
Is that 'starterware'?

hw_ints.h was #included in that program. It contains macros which enable users of both TM4C123 and TM4C129 to refer to interrupt numbers BY NAME (like INT_ADC0SS0) so programmers don't have to look up or memorize the actual numbers.

This sounds like a starterware (I think its called Tivaware for Tiva parts) program.

david genge said:

Note: in XGCONF the box labelled "Interrupt number" should be labelled "Vector number".
When will 'box' become a 'drop-down list box' containing the names of all the possible interrupts for the already elsewhere specified target processor? Bound to speed development!

Unfortunately, I doubt this will happen anytime soon. TI-RTOS kernel is supported on a lot of different devices with different interrupt mappings and names. It will require some effort to create a drop-down list for all these different devices.

david genge said:

Ashish which document discusses Hwi vs zero-latency Hwi, how to configure etc.?

The Cortex-M Hwi module cdoc covers this: http://downloads.ti.com/dsps/dsps_public_sw/sdo_sb/targetcontent/bios/sysbios/6_41_01_36/exports/bios_6_41_01_36/docs/cdoc/ti/sysbios/family/arm/m3/Hwi.html#xdoc-desc

Best,

Ashish

Processors

Processors forum

swi runs before posted