Hi everyone,

 

I am working with the BeagleBone Black trying to make the ADC and the 
PRU-ICSS work with each other for sampling an analogue signal. The issue 
that brings me here is a small-big problem I have with the external 
interrupts of the PRU-ICSS, basically it does not receive these signals. 
Although the internal interrupts work fine (PRU to PRU) and sending pulses 
to external hardware such as the host.

 

In some few words the test program I am now running in the system 
configures the ADC to start sampling data continuously and generate a 
"End_of_sequence" interrupt to the PRU0.

 

I have checked that this interrupt is being triggered correctly by polling 
the IRQSTATUS_RAW register of the ADC from the PRU directly, and checking 
the sampled data in the FIFO. (In fact this is also another way of 
bypassing the problem, but is not the most efficient nor elegant way to 
work with this device I think...)

 

I also have this problem with the EDMA3 module, there is no interrupt from 
this device to the PRU-ICSS. But this is another issue, and I think is the 
same problem as the previous one.

 

Here is the code (the important parts at least) I am running in the 
PRU-ICSS:

 

Definitions:

 

#define gmoADC 0x44E0D000 //Global memory Offset of the ADC

 

First the ADC configuration:

 

//CONFIGURATION ADC 

// 
==========================================================================

MOV MemPointer, gmoADC 

 

                        //Control register

                        MOV r1, 0x0005

                        LBBO r1, MemPointer, 0x40, 2

 

                        //TS_CHARGE_DELAY

                        //Set default value (1h)018C3040

            

                        //STEPCONFIG1. 

                                   //AIN1 (Channel 2) (+input) 

                                   //Single ended

                                   //VREFP (+ref) = 1.8 V

                                   //VREFN (-ref & -input) = GND 

                        MOV r1,0x00000001 // 0x018C3002 //After test last 
bit will be changed

                        SBBO r1, MemPointer, 0x64, 4

 

                        //STEP enable register

                        LDI r1, 0x02 //STEP1 

                        SBBO r1, MemPointer, 0x54, 4

 

                        //STEPDELAY1 Set as default

 

//Interrupt parameters

                        //IRQENABLE: End of sequence

                        MOV r1, 0x00000002

                        SBBO r1, MemPointer, 0x2C, 4

 

Configuration of the INTC (PRU):

            //Global interrupt enable PRU

            MOV r1.w0, 0x0001

            SBCO r1, INTCbase, 0x10, 2

 

            //Enable host 0 int

            MOV r1, (0x00000000|0) //(0x00000000|Host_num)

            SBCO r1, INTCbase, 0x34, 4

 

            //Map channel 0 to host 0

            LDI r2.w0, 0x0800

            ADD r2.w0, r2.w0, 0 //Add host_num to host map registers offset 
0x800

            MOV r1.b0, 0 //Channel number

            SBCO r1.b0, INTCbase, r2.w0, 1

 

            //Map system evento to channel 0

            LDI r2.w0, 0x0400

            ADD r2.w0, r2.w0, SysEvent //Add system evento to channel map 
register offset 0x400

            LDI r1.b0, 0 //Channel number

            SBCO r1.b0, INTCbase, r2.w0, 1

 

            //Clear system event interrupt

            MOV r1, (0x00000000|SysEvent)

            SBCO r1, INTCbase, 0x24, 4

 

            //Enable system event interrupt

            SBCO r1, INTCbase, 0x28, 4 

 

Now, if I keep polling the register IRQSTATUS_RAW of the ADC (and clearing 
the interrupt flag), the program works fine. But if I do the same but 
polling instead bit 30 of R31.... well that is why I am writing this....

I verify this by getting the data from the PRU's RAM using the host process.

 

I am running an Angstrom v2012.12 in a revision A5C BBB. Kernel version: 
3.8.13.

 

Someone has the same problem, knows some possible solution (appart from the 
polling)?...

 

Thank you very much!

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to