Our custom Zynq board's AD9548 appears unresponsive after initial powerup, with the Linux ad9548 driver reporting "Unrecognized CHIP_ID 0xFF". Resetting the board with our "poweron reset" switch allows the driver to probe and configure the chip, resulting in a successful "Rev. 0xC6 probed" message and the desired frequencies coming out of the chip.
Does anyone have suggestions on how to get the AD9548 to work correctly from initial startup?
Additional information:
We're using the Zynq's SPI1, which doesn't support 3-wire mode, so we've modified ad9548.c to use unidirectional mode (i.e. register 0x0000 set to 0x90). M0-M2 are pulled low with 10 kΩ resistors. M0-M7 are connected to the Zynq's PL (i.e. FPGA), but M3-M7 presumably float until the PL is loaded. Thinking that floating M3-M7 might be causing problems, we tried the "Disabling Accidental Automatic EEPROM Download" steps in the data sheet, but that didn't help.
Our board has two reset switches. Resetting the board with the "system reset" switch doesn't cause the 9548 to work. The "poweron reset" switch goes to the Zynq's PS_POR_B input and, after an inverter, also to the 9548's RESET input. The "system reset" goes to the Zynq's PS_SRST_B input, but not the 9548. Is there some state the 9548 can get into at powerup that causes it not to respond to SPI writes and reads?
We also added some debugfs support to the ad9548.c driver to allow us to send SPI commands to the chip. We tried many combinations of register writes to see if we could get the chip to respond, but haven't figured out anything useful yet. All SPI reads return either 0x00 or 0xFF when in the unresponsive mode. Once we reboot with the "poweron reset" switch, the debugfs SPI commands allow us to read and write registers fine.
Thanks,
David