Programmable Devices
CPLDs, FPGAs, SoC FPGAs, Configuration, and Transceivers
20687 Discussions

Cyclone IV E: EP4CE22F17C8 I/O pins misbehaving

AWrithingMassOfFlesh
New Contributor I
1,163 Views

Hi All,

 

I am developing with the Cyclone IV E: EP4CE22F17C8. I am observing anomalous behavior from two of the I/O pins on the chip. 

 

I have pin A11 configured as a general purpose output, however when I try to drive a signal to the pin, the output remains high. I have other pins tied to the same signal as A11, but those pins do output the signal as expected. 

 

Pin L14 is configured as MISO for a SPI bus. The problem is that this pin is being held high for some reason. I configure this pin identically to the other MISO pins in the design and those busses are working as expected. 

 

Is this a known issue with the chip? I have tried different configuration settings on these problematic pins, however the behavior does not change. I also have examined x-ray images of the PCB and there appear to be no flaws in the mounting of the chip.

 

Any insight into debugging this issue would be greatly appreciated.

 

Thanks!

0 Kudos
1 Solution
AWrithingMassOfFlesh
New Contributor I
1,000 Views

I found the issue. I was assigning the wrong pins. I was supposed to be driving A12 instead of A11 and L13 instead of L14.

View solution in original post

0 Kudos
9 Replies
sstrell
Honored Contributor III
1,149 Views

Can you show your design and any assignments you've made to these pins (pull-ups, etc.)?

0 Kudos
AWrithingMassOfFlesh
New Contributor I
1,127 Views

These are the pin assignments below. I circled the problematic pins, and also show the pins that are working correctly with the same configurations. The fact that I am applying the same assignments to these pins and getting different behavior it what I don't understand. I also use the same logic and assignments in a separate project for a different Cyclone IV device where it works as expected.

 

pd1assignments.pnggpio4assignments.png

 

 

0 Kudos
ak6dn
Valued Contributor III
1,102 Views

Are you doing this on a development board, or your own custom PCB design?

 

I have a TerAsic DE0-NANO development board which uses that same part (just a different speed grade) and I use those same I/Os as 3.3V LVTTL no problem.

0 Kudos
sstrell
Honored Contributor III
1,101 Views

It would be helpful to see code to understand how you are driving the output and how you are receiving the input.

0 Kudos
AWrithingMassOfFlesh
New Contributor I
1,075 Views

This is using a custom PCB.

For testing purposes, I drive pins A11 and A13 with a 1MHz clock signal generated by the Quartus PLL IP block. Using an oscilloscope I probe the pins, and I can see the 1MHz waveform output from A13, however, the output form A11 is a constant high signal. 

AWrithingMassOfFlesh_1-1636031823371.png

Pin L15 is the MISO to a peripheral ADC. For Pin L14 I use logic and assignments which have worked on a previous device. Moreover I have an identical interface elsewhere in this project which behaves as expected. Using the oscilloscope I can see that Pin M7 is able to be controlled by the peripheral chip. Pin L14 should behave the same but is being held high the entire time.

AWrithingMassOfFlesh_4-1636032829670.png

AWrithingMassOfFlesh_2-1636032325516.png

AWrithingMassOfFlesh_5-1636032869092.png

AWrithingMassOfFlesh_3-1636032656457.png

module ad7276(
input clk, //PLL clock 48MHz
input rstn, //PLL Lock signal
input shdn_ext, //Hardware wire OR'd laser shutdown

output reg SCK, //ADC SCK 24MHz
output reg SCSn, //ADC CS
input MISO, //ADC Master-IN Slave-OUT

output reg [11:0] MEAS, // Measurement
output reg meas_rdy
);

reg [5:0] count; // [0-13] Tconv, [14] Tacq, (b0 & b13 read 0)//0-26 Tconv, 27-28 Tacq
reg [11:0]dummy_meas;
reg SCSn_d;

always @(posedge clk)
begin
if(!rstn || (count == 38))
count <= 0;
else
count <= count + 1'b1;
end

always @(posedge clk)
begin
if(!rstn)
begin
SCK <= 0;
SCSn <= 1;
end
else if((count <= 2) || (count >= 37))
begin
SCK <= 1;
SCSn <= SCSn_d;
end
else
begin
SCSn <= SCSn_d;
SCK <= !SCK;
end
end

//CS low except during acquisition (2 clock cycles @ 48MHz)
always @(posedge clk)
begin
if(count == 38)
SCSn_d <= 0;
else if(count >= 38) //was 35. wasn't getting above 1.5V on o-scope TP
meas_rdy <= 0;
else if(count >= 34)
begin
SCSn_d <= 1;
MEAS <= dummy_meas[11:0];
meas_rdy <= 1;
end
else
begin
SCSn_d <= 0;
meas_rdy <= 0;
end
end

//Clock data_in with SCK when count = 6-28 and CS is low //deserialize miso
always @(posedge SCK)
begin
if(count >= 6 && count <= 28 && !SCSn)
begin
dummy_meas[13-((count/2)-1)] <= MISO;
end
end

endmodule

0 Kudos
AWrithingMassOfFlesh
New Contributor I
1,064 Views

Also I generated these boundary scan files, although I am not entirely sure how to interpret them. 

0 Kudos
ak6dn
Valued Contributor III
1,057 Views

Ok, you say you are using a custom PCB of your own design. Is there just one instance you have built, or do other board(s) exhibit the same problem?

0 Kudos
AWrithingMassOfFlesh
New Contributor I
1,040 Views

I am seeing the problem on multiple boards with the same design from the same batch. We have x-rayed the PCB's and seen that the FPGAs are mounted properly. At this point, we suspect the issue is either with the chips themselves or with the synthesis.

pre-config                                                        post-config

AWrithingMassOfFlesh_0-1636121556079.png

Can someone explain what these lines mean in the boundary scan files I uploaded? It looks like Pin L14 is present in the pre-configuration file but absent from the post-configuration file. I want to rule out the possibility that I am using the wrong configuration in Quartus. I'm using Quartus v20.1.1

 

0 Kudos
AWrithingMassOfFlesh
New Contributor I
1,001 Views

I found the issue. I was assigning the wrong pins. I was supposed to be driving A12 instead of A11 and L13 instead of L14.

0 Kudos
Reply