AM263P4: Can XBAR be used to map ADC0_EVT1 to PRU_0 interrupt.

Hi Nathan

Could you go through the PRU-ICSS Local INTC, it talks about the configuration of interrupts for PRU-ICSS.

You can use it to map the corresponding OUTPUTXBAR signal to interrupt controller for ICSS.

Regards,
Akshit

You have failed to describe how to correctly setup the OUTPUTXBAR in SysConfig for this application. I have read the section in the technical guide concerning the OUTPUTXBAR, but it doesn't align with what is happening in SysConfig. The technical guide also makes it appear as though the OUTPUTXBAR can only be mapped to the interrupts of PRU1 and not PRU0. I need clarification.

I have reviewed this section in the correct technical guide for the AM263P4. It appears that the OUTPUTXBARS get mapped to events 48 through 63. Are there any c code examples on how to setup these interrupts or am I on my own to decipher the technical manual and register addendum to get this setup?

Hi Nathan,

Nathan Ostrye said:

It appears that the OUTPUTXBARS get mapped to events 48 through 63.

Correct, as can be seen from the TRM as well

using this information:

I set the above configuration for OUTPUTXBAR, selecting the required Adc event (You may select any OUTPUTXBAR here)

Now, In ICSS configuration:

I select the input signal as 63, which if we check from the TRM is mapped to OUTPUTXBAR15.

Now you can check the status registers to see if an interrupt is being registered!

7.3.7.1.1.2 PRU-ICSS Interrupt Status Checking

The next stage is to capture which interrupts are pending. There are two kinds of pending status: raw status
and enabled status. Raw status is the pending status of the interrupt without regards to the enable bit for the
interrupt. Enabled status is the pending status of the interrupts with the enable bits active. When the enable bit is inactive, the enabled status will always be inactive. The enabled status of interrupts is captured in interrupt
status enabled/clear registers (ICSS_INTC_ENA_STATUS_REG0 to ICSS_INTC_ENA_STATUS_REG4).
Status of interrupt 'N' is indicated by the N-th bit of ICSS_INTC_ENA_STATUS_REG0 to
ICSS_INTC_ENA_STATUS_REG4. Since there are 160 interrupts, five 32-bit registers are used to capture the
enabled status of interrupts. The pending status reflects whether the interrupt occurred since the last time the
status register bit was cleared. Each bit in the status register can be individually cleared.

Let me know if this helps!

Regards,
Akshit

I fear that there is a missing step here somewhere.  Currently, I have RTI1 generating an interrupt at 32Khz. The RTI1 interrupt was as working properly by creating an ISR function that toggles a hardware output.  The RTI1 interrupt is then used by ADC0 Burst mode to start a 6 SOC burst. ADC0 has an interrupt configuration for ADC Interrupt 1 set to the end of conversion for SOC/EOC15.  This interrupt was verified as functioning correctly by creating a test ISR that toggles a hardware output.  At this point in the operation, it has been validated that ADC0 Interrupt 1 is working as expected.

I have the Output XBAR configured to use "ADC0_EVT1" using OUTPUTXBAR8. SysConfig appears to generate code for this, and I have not modified or added additional code for this configuration. I am using the default pins (C8) for this and monitoring it with an oscilloscope. No matter how I configure the Output XBAR configuration, no change in signal level is seen during runtime. I can change the logic high/low level seen at runtime by changing the Invert XBAR Output setting. I have tried every combination of settings in the Output XBAR configuration, but still cannot see any change in the status of the output after initialization.

I also created a while loop to monitor the value of register 0x48020204, which is the ICSSM_PR1_ICSS_INTC_INTC_SLV_RAW_STATUS_REG1 Register. It is always 0 when verified using the same output toggling methodology as previous tests.

Hi Nathan,

Apologies for the delayed response, I realize you only need to pass the interrupt and not the event!

I have a working solution for you, built on the example adc_soc_rti.

1. OUTPUTXBAR has two inputs connected to INTXBAR.
   
   
2. Select one of these as what OUTPUTXBAR will output.
3. Map your ADCx_INTy to the same INT_XBAR
   
4. Configure ICSS to use the same outputxbar for INTC.
   
5. Register the interrupt in code(You can refer the same adc_soc_rti example for this)
   

After this I ran the program, and got following outputs verifying my expectations:

1. Interrupt output on scoping OUTPUTXBAR8
   
2. Value change at
   

Please let me know if it helps!

Regards,
Akshit

Thank you for the reply. I was able to replicate your results following the steps you have provided. Unfortunately, it doesn't fully meet my requirements.

For my implementation, I wish for the interrupt handler to be on the PRU. More specifically, I do not want the R5 core to have interrupt handlers for the ADC EOC. With the implementation described, it is not possible to avoid an interrupt handler when using the INT XBAR. I have tried not setting the callback as well as setting the value to NULL, both of which result in a failure of the HwiP_construct function. 

The simple goal for this functionality is to have the PRU handle all functionality associated with the ADC end of conversion. The R5 core can do the setup and initialization of any XBAR or ICSS instances needed, but the implementation should not require intervention of the R5 when the ADC end of conversion occurs. I had hoped that the XBAR could help accomplish this.

Hi Nathan,

This is just routing the signal to PRU's Interrupt Controller.

Akshit Pareek said:

Register the interrupt in code(You can refer the same adc_soc_rti example for this)

You don't need to register this interrupt in R5, and you should still be able to get correct results.

Nathan Ostrye said:

The simple goal for this functionality is to have the PRU handle all functionality associated with the ADC end of conversion. The R5 core can do the setup and initialization of any XBAR or ICSS instances needed, but the implementation should not require intervention of the R5 when the ADC end of conversion occurs. I had hoped that the XBAR could help accomplish this.

This is exactly what is happening in this scenario.

Let me know if you need more information on this!

Regards,
Akshit

Thank you for the reply, I was able to get one step closer. I was able to measure the expected output on pin C8 indicating that the Output XBAR is transferring the ADC end of conversion event as expected. I was also able to read register 0x48020204 and validate its value was changing as expected.

Unfortunately, I'm not having success with the PRU reading the 0x48020204 register. I have added the code:

#define PRU_INTC  (*((volatile unsigned long *)0x48020204))

void main(void)
{

unsigned long ui32_interrupt_flags;

while(1){
    ui32_interrupt_flags = PRU_INTC;
    if(0 < ui32_interrupt_flags){
        ui32_interrupt_flags = 0;
    }
}
}

This code is just polling the 0x48020204 register then resetting a variable value when the register value is greater than 0.  This allows me to set a breakpoint when that variable gets set so that I know that I'm correctly able to trigger the operation of the PRU.  I never see that breakpoint get hit.

For additional detail, I placed an interrupt handler on the R5 core to allow me to set a break point on that processor then check the value of 0x48020204. The hope is that I could then read the same thing from the context of the PRU.  When viewing from the R5 perspective:

When viewing from the context of the PRU:

I've had my share of struggles reading data off of the PRU, but I am able to step through the PRU code as expected and set working break points. I do not believe it to be a debugging related issue. I believe there is still another step required to get the PRU to read the value I'm looking for.

Hi Nathan,

Could you please help me understand the issue on PRU side that you are facing?

The issue is that the PRU is not receiving any type of signal across the Output XBAR that the ADC has completed its conversion. As documented above, the Output XBAR is being populated as expected when the ADC completes its conversion. However, the PRU is not able to correctly access that signal for some reason.

Probably some configuration issue,

If I understand this correctly you are mapping the XBAR output interrupt to ICSS interrupt right?

It could be mapped to an ICSS interrupt, or the PRU could poll the Output XBAR register. Either approach would work for my application. 

I am trying to setup the infrastructure to allow the PRU to handle data parsing at the end of an ADC conversion without any R5 intervention during runtime.

Are you not able to read the Output XBAR register?

Or is the ICSS interrupt mapping the challenge here?

As noted in an earlier reply, I am attempting to read the Output XBAR on the PRU. Please review that comment for full details and screen captures.

I see that when you are reading from PRU context the address that you are looking at is the global SOC address, Can you please let me know what value you see if you look from the PRU Memory Map - 0x20204

I am able to see the correct signal from the PRU at 0x20204 change to something other than 0. However, I have observed that this value does not automatically reset to 0. I suspect that there is a different register which much be told to clear this status. Or perhaps that I need to use the PRU interrupt functionality instead of simply polling the value of register 0x20204.

I was able to clear this value by writing a value of 56 to register 0x20024.  I am now seeing the signal I am needing on the PRU.