Hi,I've been trying to control a simple SPI LED driver IC using the SPIM0 unit in my cyclone V HPS. The problem is that the alt_spi_is_ready() function doesn't do what I expect it to do. Before initiating a write, my software first calls alt_spi_is_ready() to see if the SPI unit is busy. However, that function always returns 'false', even if the SPI unit is still transferring data. This causes my software to continue writing new words to the SPI unit, causing the previous transfer to be corrupted. I've looked at the Altera-SoCFPGA-HardwareLib-SPI-RW-CV-GNU example code and this project uses alt_spi_is_ready() too. So what am I doing wrong? Has anyone gotten the HPS SPI unit to work properly? I'd like to know.
Hi Aldridge,I'm confused by your question. We don’t have an alt_spi_is_ready() API - can you please double check the API you are having trouble with? Also, we have a known limitation with SPI in mode 0. The example we provide uses SPI mode 3, and it works. What mode are you using, and what mode does the SPI LED driver IC support? If the LED driver IC supports mode 3, please give that a try. Let me know how it goes. Regards, Sue
Hi Sue,The function I was having trouble with is called alt_spi_is_busy(). It is part of the altera HWLIB. I didn't check my post properly before posting it. I'm sorry about that. The LED driver that I'm trying to control is a MAX6966AE. I'll check the datasheet to see what modes it supports.
By the way, could you tell me what the known limitation in SPI mode 0 is? I've searched the cyclone V errata sheets and couldn't find anything related to the SPI controller.
Hi Alrdridge,I looked at the MAX6966AE data sheet and it expects Mode 0. The issue is that the slave select signal is toggled between frames when SCPH=0 (see figure 19-7 in the CV data book). This behavior can cause a problem with some peripherals. Try mode 3 with your device. Regards, Sue