Jump to content
  • 0

Arty A7 35t SPI stops working for one of the ICs


hdx

Question

Hello,

I am currently using the FPGA to run an ADS8638 and mc33972 by switching between the CS. The problem I have noticed is that when I run the init for both the work perfectly however after initializing an GPIO interrupt on my board the mc33972 SPI stops working and just halts when performing an XSpi_transfer(). However, it still is working for the ADS8638. Both ADS8638 and mc33972 are using the same SPI IP with same address and id, i.e., it is shared between each other. But, XSpi_transfer from ADS8638 works without any problem but not for mc33972 after running this function in interrupt init: 

XGpio_InterruptEnable(InstancePtr, 0xF);

Any idea why? 

Also, I am running rtos if it might be something that could be the problem. 

Link to comment
Share on other sites

5 answers to this question

Recommended Posts

The first thing that I'd do is read the the datasheets for both devices. No, really, I'd do that before trying to build a bitstream or start trying to code anything. Understand how each expects the SPI interface will work. Some devices are flexible and some are not. There's SPI as a generic interface term and SPI as a specific standard.

As a general concept SPI is pretty straight-forward. Once you consider the specifics of individual components it can get pretty complicated. There are a lot of options, like clock phasing, that make any specific implementation of the SPI interface fail on one of your devices. I'd start with working out the specific timing for each relative to what your hardware and software think you want to implement to see possible issues that you might not of though about.

If you are new to coding for an RTOS then you can expect to run into unhappy surprises.  

Link to comment
Share on other sites

Hi,

Thanks for the help.

The SPI devices works flawlessly when using them without the interrupts for my GPIO ports.However, As fast as I enable the GPIO interrupt the mc33972 device fails to transmit data. So everything is working correctly but the interrupt somehow does something that cause the mc33972 to fail. I have configured the devices correctly with right options so should not be the problem also the clocking in hardware is set correctly.  I might suspect that there is something that cause the transmit tx empty bit not to be set when the interrupt is enabled.

I'll continue digging around maybe I'll find something. Asked the question here in case anybody would have stumble across this problem before and would have any suggestions why this happens.

Link to comment
Share on other sites

I'd personally be looking into the interrupt controller setup as that seems to be the portion that, based on your description, is dropping communication with the mc33972 but the ADS6838. There are a few Xilinx threads with similar problems regarding here, here, and here.

Otherwise, you described the two devices as connected to the same IP, sharing the same MOSI, MISO, and SCK (but not CS)? I realize that the SPI protocol is designed to be used this way, but I do have to wonder if it's being properly supported in software.

Thanks,
JColvin

Link to comment
Share on other sites

Hello,

Yes that is correct the same SPI IP is shared between MC33972 and ADS8638. The MOSI, MISO AND SCK is shared between these two modules, but the CS is unique for each module.

I'll look into these threads and see if I could find something that would solve this problem. The weird thing is how the interrupt for an GPIO could cause the SPI IP from working.  

Link to comment
Share on other sites

Hello,

I have now for a few days tried to debug and see where the problem is, however can't seem to get any understanding why the SPI would cause this problem, specially for only the mc33972 when the both mc33972 anhd ADS8638 are connected to the same ip block but with different CS.

From the debugging I have made I have noticed also if I comment out the usage of mc33972 that the interrupt triggers but when getting the gpio interrupt status it fails, and this is due to that it says that the flag bit in the passed instance ptr is 0x22222222??? 

When checking the ptr it seems to be the intc ptr and not the xgpio ptr I passed in XIntc_Connect? Also the the interrupt fails inside XGpio_InterruptGetStatus when it executes the following line Xil_AssertNonvoid(InstancePtr->InterruptPresent == TRUE); as I mentioned above since the bit is 0x22222222, when it should either be 0 or 1. This is because it receives the intc ptr and not the xgpio ptr. Could there be some register error that cause the whole mc33972 and xgpio to collide somehow.

Link to comment
Share on other sites

Archived

This topic is now archived and is closed to further replies.

×
×
  • Create New...