New Z7010 SoM's Not Working Out of the Box

Could you check and make sure that the new boards are configured in the same was as the original MicroZed. If you are attempting to load your application from JTAG jumpers JP1, JP2 and JP3 should all be set 1-2 (jumper away from the edge of the board).

The USB-UART device on the MicroZeds each have a unique ID so each one will enumerate with a different Comm Port on your PC when using a terminal like TeraTerm or Putty. You can open up the Device Manager in Windows Control Panel to see which Comm port is assigned to the board currently connected to the PC.

And finally, check and make sure that all of your MicroZeds are '7010' and not '7020' MicroZed SOMs as a '7010' application will not run on a '7020' device without modification.

-Gary

Each time we re-run the application we are sure to update the comm port as per the Device Manager. We are also sure to change the header settings from QSPI to the JTAG JP1-JP3 (1-2 setting) each time we try to program the FPGA and run our application through SDK.

I think I've managed to flash the bootloader and override the factory boot; but even from this mode (with the correct headers on JP1-JP3 set) we still cannot communicate with the device.

We've also checked to make sure that they are all 7010 boards, as we've had the exact same problem with other 7020 boards we own.

One other possibility to check is adequate power. If you are connecting the MicroZed boards 'standalone' (no Carrier Card suppling power) via the USB-UART connection, and that is the only power to the MicroZed, is it possible that the USB port does not supply adequate power for your application. I guess it is possible that the original SOM is requires just a little less power than typical. Could you try using an 'active' or powerd USB source or at least use a different USB port to test.

-Gary

Hi Gary, I am working on this as well.  I would think that it is getting adequate power.  We program the first board (which came with an eval kit) using the same method.  The modules we purchased individually (3 of 6 tried thus far), won't even program via JTAG.  The odd thing is that we can program the eval board just fine, but not any of the other 3 we have tried.  I have a hard time believing that we have 3 bad boards right out of the shoot so we must be simply overlooking something (hopefully).  Is there anything different in the eval boards than the SoM modules?  I tried looking each over and visually comparing but I don't see any difference.

Any help is appreciated.  Thanks.

I have seen issues with some USB ports being very limited in the power they can supply so you might check to make sure.

There should not be any difference between the Eval MicroZed and the 'SOM;. The Eval kit is just a SOM packaged with a voucher for the Xilinx tools along with a microSD Card and a cable.

I assume you are using the MicroZed boards 'standalone'. If you are using them on a carrier card you will need to connect the JTAG cable to the connector on the Carrier Card, not the MicroZed.

If your application might be demanding more power you might try a simple 'Hello World' app to see if that works. Another data point would be if both your original MicroZed and the new ones can boot and run an application from the microSD port. There is a Linux MicroSD card archive you can download from the MicroZed documentation page if you need an image to try: http://picozed.org/support/documentation/1519

If the new boards can boot and run from both QSPI and microSD card but not JTAG please make a visual inspection of the JTAG connector on the MicroZed as well as the Boot Configuration jumpers.

Let us know what you find.

-Gary

We've just tried using our custom carrier card to power the MicroZed boards (we've also used the commercial BKO carrier card to try and program) and we see similar results: the FPGA done blue LED comes on but our application does not run.

We are going to try to get our original board working with no debugging enabled in SDK, then try to use the new boards. The hope is that the rebuild we are forced to do each time we change comm ports is no longer a factor and we can compare apples to apples with zero changes being made. We will also be trying to program the new boards following the tutorials in hopes that we realize something in our setup causing the issues with the new boards.

Unfortunately the MicroSD card route is not something we can do, but we have verified that the factory bootloader runs from the QSPI on the new boards.

At this point I think we can rule out power being the issue.

Was this resolved? Something you said in your last message has me confused. Are you rebuilding the Xilinx project for each different board to account for the COM port differences? If so, that is not necessary. The COM port differences do not affect the Zynq side, which is just a simple Rx/Tx UART connection to the CP2104. The COM port differences affect the CP2104-to-PC connection and how the PC enumerates and communicates with that particular transceiver.

When you say that your application does not work, what exactly does that mean? Is there no terminal output? Does the processor hang? Are you not able to step through the code in the SDK debugger?

Bryan

Bryan,

This was resolved...sort of.

To answer your questions; yes there was no terminal output, we had verified that we loaded the correct hardware onto the board, but when we ran our application we received no response back on the terminal and the UI we created to send commands to the board via ethernet would not connect to the device.

Between the different XC7Z010 boards the only thing we changed was the Comm port number in the Run Config settings. We would go from our original board which worked, swap in a new board, change the comm port, program hardware, and then fail when running the app.

As it turns out, there was an error in our software environment that I had been overlooking. For whatever reason we still had no problems using our original board with the error. As soon as we dove into our SDK project (we changed the format of our command interface) and got rid of the error we could then program all of the boards. It seems strange that we could program our original board but not the others while the SDK error persisted..but we seem to have a working setup now.

Thanks for your input!