Differences between PicoZed 7Z030 REVC01 and REVC04

Hello Wdecook,

I am currently looking into your issue. Could you provide me with some information. When you have your PicoZed on your customer carrier and the blue FPGA_DONE light comes on, do you recieve any data from your USB-UART through a  Terminal program on your host PC, and if yes what is the terminal output?

Also have you taken a look at the PicoZed Errata yet? "PicoZed 7015/7030 Rev C Errata 1.3" http://zedboard.org/support/documentation/4736

Specifically sections 3.2, 3.4, 3.5

--Josh

I can't reproduce the problem today. It seems that I've said all of the proper four-letter words in the correct order. I'll put in a bit more effort towards trying to replicate the issue, but I don't want to ruin a good thing.  

The problem is back. I opened up a couple more of the new picozeds and attempted to use them. Same issue - DONE light comes on when pl hasn't yet been configured and I can't see the device on JTAG.

I followed a trail of fluctuating power sources and power source enables back to find that PWR_ENABLE was oscillating. Item 3.5 of the picozed errata shows that the newer boards have R52 removed because this was pulling up the enable pin of the TPS54618 to a voltage higher than the maximum. After placing a 10k resister in R52, the picozed REVC04 works like normal. 

I have two main questions:

Why do the picozeds without the PWR_ENABLE pull-up cause PWR_ENABLE to oscillate on my custom carrier board and not on the FMC Carrier? Control of PWR_ENABLE on my custom carrier is similar to that on the Avnet PicoZed FMC Carrier C03. The MOSFET is a BSS138LT1G (same as on FMC carrier), but the controlling voltage is +15V, R103 has been changed to 1k, C92 to 0.1uF, and R106 to 20k.

Is the EN pull-up to 5V really detrimental to the TPS54618? I have been running picozeds with this pullup constantly for months now without any of them failing. Also, the details of the current pull-up within the regulator aren't clear to me. I suppose I want to know more information about the enable comparator in the TPS54618.

Looks like we're not quite out of the weeds yet. Now I can see the devices on the jtag chain and program the fpga over jtag, but I can't write to qspi flash. Rather, I can't erase the the qspi. When programming flash using SDK->Xilinx Tools->Program Flash, the process fails at the blank check operation. I see this behavior on 3 separate REVC04 picozeds.

Hello Wdecook,

I would highly suggest that you do not modify your PicoZed SOM. Your custom carrier card appears to be at fault in this case. If you are willing to share the schematic to your carrier card, I can take a quick look over it and see if anything jumps out.

Other then that I am going to suggest that you take a look over the PicoZed  Carrier Card Design Guide and Hardware guide in hopes of finding your mistake.

http://zedboard.org/support/documentation/4736

--Josh

Josh, 

Can I email the schematic directly to you?

Hello wdecook,

If possible could you host it on some file hosting website (somthing like google docs would work) and then send me a private message with a link.

Thanks,

Josh

This issue has been resolved. Pulldown resistors at the reset buttons on my carrier had been marked DNI, but were populated. This left CARRIER and POR resets in states somewhere between high and low logic. I was just getting lucky with the REVC01 picozeds.

Hi Wdecook,

Excellent news! Glad you were able to find the problem, and thanks for responding back with your solution!

--Josh