GP Interrupt feature on ADRV9026

ADRV9026 device features two General Purpose Interrupt pins, GPINT1 and GPINT2 per the datasheet pinout. The GPINT pins provide an interface that allows the device to inform the BBP of any errors or warnings encountered in normal operation. Examples of the interrupt sources include PLL unlock events, SERDES link status, a stream processor error, or JESD link drops. A full list of interrupt sources is provided in GENERAL PURPOSE INTERRUPT section of the user guide. While the two GP interrupts are equal in priority, ADI suggests allowing the GPINT2 pin to act as the high priority interrupt pin whereas GPINT1 can act as the low priority interrupt pin. This means that the user can treat GPINT2 pin as a high priority interrupt and associate catastrophic error sources to this GP INT pin. For example, PLL unlock events, ARM crash events, JESD link drop events, can be tracked via GPINT2, whereas lower priority errors such as CP overrange, low level JESD errors can be tracked via GPINT1 pin. This empowers the user to create two different error recovery mechanism functionality based on the error reported. The user can refer to the GPINT section (Table name GP_INTERRUPT Bitmask Description – API Recovery Section) of user guide to get an idea of the distinction between high/low priority errors. Both these pins can be configured with independent bitmasks that controls which signals can assert GPINT1 or GPINT2. GP interrupt mapping is left to the user’s discretion.

Below are a few example experiments the user can use to test out GP INT pins on their system –

1. Forcing ARM to create a GP Interrupt – The user can write 0x1 to register 0x8D to force ARM to generate an interrupt on the GPINT pin (D15 gets asserted). Please note that the other GpInt sources (D12, D14) cannot be simulated (using spiWrites) as they are related to a true catastrophic failure. The ARM system error source GP INT source (D12) is triggered by the hardware and does not depend on the ARM operation.
2. RF1 PLL unlock event – After setting up the GP INT mask as mentioned in the user guide, the user would need to write the register 0x2A02 to 0xF to completely power down the RF1 PLL. This would cause the GP INT status to be asserted and assert the corresponding GP INT pin. The user can check that the RF1 PLL is unlocked using the API function adi_adrv9025_PllStatusGet.
3. RF2 PLL unlock event – After setting up the GP INT mask as mentioned in the user guide, the user would need to write the register 0x6402 to 0xF to completely power down the RF2 PLL. This would cause the GP INT status to be asserted and assert the corresponding GP INT pin. The user can check that the RF2 PLL is unlocked using the API function adi_adrv9025_PllStatusGet.
4. AUX PLL unlock event – After setting up the GP INT mask as mentioned in the user guide, the user would need to write the register 0x2602 to 0xF to completely power down the AUX PLL. This would cause the GP INT status to be asserted and assert the corresponding GP INT pin. The user can check that the AUX PLL is unlocked using the API function adi_adrv9025_PllStatusGet.
5. SERDES PLL unlock event – After setting up the GP INT mask as mentioned in the user guide, the user can clear bit 0 of the register 0x6846. This will cause SERDES PLL to unlock and assert the corresponding GP INT pin.
6. CLK PLL unlock event – After setting up the GP INT mask as mentioned in the user guide, the user would need to write the register 0x2802 to 0xF to completely power down the CLK PLL. This would cause the GP INT status to be asserted and assert the corresponding GP INT pin. The user can check that the CLK PLL is unlocked using the API function adi_adrv9025_PllStatusGet.

The user would need to reset the device after running each of the above tests. Please note that these experiments should only be used during lab evaluation.

It should be noted that the GPINT status and the GPINT pins have different behaviors. The GPINT pins are real-time indicators of error status whereas the GpInt status bits are sticky and remain set until cleared using GpIntClearStatusRegister API function. For example, if a PA protection error occurs when PA protection is configured in the autoclear mode, the GPINT pin will de-assert after the power returns to normal. The GPINT status bitfields are sticky and remain asserted until the user clears the register. If the PA protection error occurs and disappears in autoclear mode, the GPINT status will still indicate a PA protection error occurred until the user manually clears the GPINT status.

ADI does not recommend monitoring for certain GPINT sources such as Framer IRQ0:Framer0 lane FIFO pointer error, as these sources are expected to get asserted due to the way in which link sharing mode is set up on ADRV9026. For certain profiles in linkSharing mode where Rx and ORx sample rates are not the same, the JESD clock domains are swapped between the Rx and ORx rates which could cause Framer 0 lane FIFO pointer error to be asserted. This is expected and is not an issue, it is safe to ignore this error.