Using ZC706 and ADRV9371, we have been working on our no-os code and have working DDS and was just working through DMA issues when Analog released their no-os code. Since it seemed Analog's was just as far if not further and would get better support, I decided to switch over to that. Unfortunately, I can't get the jesd stuff to come up properly.
In our no-os implementation, I did have a problem that I was just working around. When programming the FPGA, the very next application launch would result in failed jesd bring up and I'd just see LO leakage. If I didn't reprogram the FPGA or reset the system, then it would work. I took this as an initialization issue and would circle back once other things were working.
Here is the console output right after FPGA programmed when it doesn't work right:
SUCCESS: MYKONOS_waitInitCals
SUCCESS: Calibrations completed successfully
SUCCESS: MYKONOS_enableSysrefToRxFramer
SUCCESS: MYKONOS_enableSysrefToObsRxFramer
SUCCESS: MYKONOS_enableSysrefToDeframer
SUCCESS: MYKONOS_resetDeframer
SUCCESS: MYKONOS_enableSysrefToDeframer
SUCCESS: MYKONOS_readRxFramerStatus (3E)
SUCCESS: MYKONOS_readOrxFramerStatus (3E)
SUCCESS: MYKONOS_readDeframerStatus (21)
SUCCESS: MYKONOS_enableTrackingCals
SUCCESS: MYKONOS_radioOn
SUCCESS: MYKONOS_setObsRxPathSource: OBS_RXOFF
SUCCESS: MYKONOS_setObsRxPathSource: OBS_INTERNALCALS
*** EVERYTHING INITIALIZED ***
SUCCESS: MYKONOS_jesd204bIlasCheck (D8)
Note, when I saw SUCCESS: MYKONOS_readDeframerStatus (21) and MYKONOS_jesd204bIlasCheck (D8), I knew that things were not working and the analyzer would confirm with just LO. Just running the application again would result in good jesd and the tones were observed on the analyzer as expected.
SUCCESS: MYKONOS_waitInitCals
SUCCESS: Calibrations completed successfully
SUCCESS: MYKONOS_enableSysrefToRxFramer
SUCCESS: MYKONOS_enableSysrefToObsRxFramer
SUCCESS: MYKONOS_enableSysrefToDeframer
SUCCESS: MYKONOS_resetDeframer
SUCCESS: MYKONOS_enableSysrefToDeframer
SUCCESS: MYKONOS_readRxFramerStatus (3E)
SUCCESS: MYKONOS_readOrxFramerStatus (3E)
SUCCESS: MYKONOS_readDeframerStatus (68)
SUCCESS: MYKONOS_enableTrackingCals
SUCCESS: MYKONOS_radioOn
SUCCESS: MYKONOS_setObsRxPathSource: OBS_RXOFF
SUCCESS: MYKONOS_setObsRxPathSource: OBS_INTERNALCALS
*** EVERYTHING INITIALIZED ***
SUCCESS: MYKONOS_jesd204bIlasCheck (4)
When I saw SUCCESS: MYKONOS_readDeframerStatus (68) and MYKONOS_jesd204bIlasCheck (4) (or just 0), analyzer showed expected output.
So when I plugged in the Radioverse generated files into the ADI no-os, I was surprised to have worse initial results:
Please wait...
MCS successful
CLKPLL locked
AD9371 ARM version 4.0.6
PLLs locked
Calibrations completed successfully
RX_XCVR initialization OK
TX_XCVR initialization OK
RX_OS_XCVR initialization OK
RxFramerStatus = 0x20
DeframerStatus = 0x21
dac_setup dac core initialized (61 MHz).
adc_setup adc core initialized (31 MHz).
ERROR: [MYKONOS_jesd204bIlasCheck] Error:
ERROR: [MYKONOS_jesd204bIlasCheck] deframerStatus (D8)
Done
RxFramerStatus is either 0x20 or 0x25. The MYKONOS_jesd204bIlasCheck deframerStatus is always 0xD8 instead of 0 or 4 like I want to see. Skipping FPGA reprogramming and resetting the system each time did not work around it like it did in our no-os code.
Is it as bad assumption that Radioverse will only generate valid profiles? I thought there was error checking/prevention such that Radioverse would prevent invalid settings. Before, when our no-os was not working as expected, I blamed that on initialization code not being quite correct. But when the ADI no-os doesn't work out of the box, and all I had to do was generate profiles and add them to the code, that makes me suspect the profiles are bad.
Any suggestions on where to focus my debugging efforts? In the ADI code, the first sign of problems is the xFramerStatus' not being as expected. It would be nice to get our no-os code working, but at this point, it's more important for me to get the ADI no-os code working properly.
Thanks in advance for any advice.