ADRV9009-ZCU106 no-OS (headless_arm.c) – TALISE_verifySpiReadWrite() fails at scratchpad write

Hi anshum ,

Are you using the ADRV9009 no-OS example: https://github.com/analogdevicesinc/no-OS/tree/main/projects/adrv9009 ?

Regards,

G

Yes, I am using that exact repo for the no-OS firmware on Vitis 2023.2, and I have built it using the provided makefile as suggested in the ADI directories. I am running the headless_arm.c application without any custom modifications.

The sample project should run without any modifications, provided that the HDL is also correct. Are you using the main branches for both no-OS and HDL? We will test the sample project on our side.  

Regards,

G

Yes, I am using the main branches for both no-OS and HDL. To clarify:

• The HDL reference design in the ADI 2023.3 hdl repo is provided for the ZCU102 board, while in our setup we are using the ZCU106.
• As per the ADI HDL porting guide, we ported the design from ZCU102 to ZCU106.
• During this porting process, we made sure that all TCL scripts and especially the constraint files were adapted carefully for the ZCU106, and then cross-verified them against the ZCU106 schematics.
• For the no-OS build, we simply used the provided makefile and built it from the command line, exactly as described in the ADI directory.

As an additional confirmation:

• The JESD lanes are being established correctly in our build, which further indicates that the HDL constraints are valid.
• The SPI reads (Vendor IDs 0x56 and 0x04) are working fine as well, so connectivity and constraints appear correct.
• The issue arises only with SPI writes (specifically the scratchpad check in TALISE_verifySpiReadWrite()), which is why we are trying to narrow down whether it’s a driver/API guard condition or a hardware initialization nuance.

Update on SPI write/read issue

I added extra debug instrumentation in the no-OS project to check what is actually written and read back from the ADRV9009 scratchpad register. The vendor ID reads are fine (0x56 / 0x04), but whenever I try to write any value to the scratchpad register, the read-back is always 0x49.

For example:

So it’s not simply a bit inversion or complement - the return value is fixed at 0x49 regardless of the value I attempt to write.

halError=0 is returned from the SPI HAL calls, so from the driver’s point of view the SPI transactions are successful, but the device never seems to latch the written value.

This makes me suspect either:

• a misalignment/timing issue in the SPI transfer (mode, edge, bit-order),

• or the scratchpad write is being ignored due to some device state / reset / protection.

Could you confirm whether always reading 0x49 is expected behavior when writes fail, or if this points to a wiring / SPI mode configuration problem in my HDL port (ZCU102 to ZCU106)?

Hi anshum ,

It is hard to debug a custom design, but I would double check to see if CS and RESET are working correctly. Furthermore, have you tried changing the SPI mode or lowering the speed? I would start by verifying reads/writes in the function where SPI communication is initialized: https://github.com/analogdevicesinc/no-OS/blob/ae557a33b786eddd5818992da529489e1cc80f73/projects/adrv9009/src/devices/adi_hal/no_os_hal.c#L83-L86 

Regards,

G

Hi anshum ,

Did you manage to fix the problem you were having?

Regards,

G

Hi anshum, 

Do you have any updates regarding this thread?

Regards,

Bianca

Closing this thread due to inactivity.