Having trouble successfully loading a bitstream to Sncikerdoodle Rev 3 board

[ghirma...@gmail.com]

Hi,

I’ve been having trouble successfully uploading a bitstream to the Snickerdoodle Rev3 board. Originally I was using my own generated bitstream but wasn’t having success (it would load using the linux method found here, under “Programming the PL through Linux”, however I wasn’t getting any output from the snickerdoodle FPGA pins).

To test that it wasn’t my bitstream that was the issue, I used the Snickerdoodle GPIO example project. Here were my steps and environment:

Using the “Building Bitstream into BOOT.bin” method found on page 9 of “Snickerdoodle Hardware Configuration Guide”

1. First locate the GPIO bitfile. I pulled it  (system.bit) from “snickerdoodle-linux-prebuilt”

2. My linux environment is running based on the snickerdoodle-linux-prebuilt files, meaning the BOOT.bin and config.txt/uENV.txt file already includes a command to run “system.bin” upon boot up. This is based on if there is a system.bin file located in the SD card, so I put the system.bit file there

3. After booting up snickerdoodle by plugging it to my computer through USB, I enabled a serial interface to pull up it’s command prompt.

4. I followed the instructions found in the readme file, and ran the commands found in the readme “examples” to turn those pins high. Using a multimeter, I wasn’t able to get any voltage from those pins

5. I followed the troubleshoots found in the forum but this didn’t resolve the issue

Using the “Loading Bitstream from Linux” method found in the Hardware Configuration Guide

1. Using the system.bit file found from Step 1 in my first method above, I followed the instructions to convert the bitstream into a reverse bitstream by using the boot.bif file found here. I imported the .bif file into the Xilinx SDK and adjusted it so that the correct files were being pointed to in my local machine (so system.bit had the correct file path etc).

2. After creating this .bif file, I ran the

   “bootgen -image boot.bif -split bin -o i BOOT.bin”
   
   command to split the files in order to get the reverse bitstream file “system.bit.bin”

3. I then uploaded the “system.bit.bin” file into snickerdoodle using sftp

4. I ran the commands to upload the reverse bitstream onto the board

   cat [path/to/bitstream] > /dev/xdevcfg

   
   and also ran the command that tells if it was successfully loaded (had to adjust the original commands for my environment)

   cat /sys/devices/soc0/ambaf80070000.devcfg/prog_done

   
   , which it stated as loaded (gave me “1” which meant correctly loaded)

5. After confirming the bitstream was loaded, I followed the instructions found in the readme file, and ran the commands found in the readme “examples” to turn the pins high. Using a multimeter, I wasn’t able to get any voltage from those pins

Is there anything I’m doing wrong, maybe my steps are incorrect?

Is it perhaps the fact that I simply copy and pasted the system.bit file from the GPIO file into my SD card (but confirmed that uENV.txt included system.bit upon bootup)? Here are my uENV.txt file

uENV.txt

bootargs=console=ttyPS0,115200 root=/dev/mmcblk0p2 rw rootwait earlyprintk
bootdelay=3
bitstream_image=system.bit
configenv=config.txt
loadconfigenv=load mmc 0 ${loadbootenv_addr} ${configenv}
importconfigenv=echo Importing configuration environment...; env import -t ${loadbootenv_addr} ${filesize}; echo Config set to ${config_dir}
mmc_loadbit=if test -e mmc 0 ${bitstream_image}; then echo Loading bitstream ${bitstream_image} from microSD to RAM... && fatload mmc 0 ${loadbit_addr} ${bitstream_image} && fpga loadb 0 ${loadbit_addr} ${filesize}; fi;
boot_snickerdoodle=mmcinfo; echo Copying Linux system from microSD to RAM...; fatload mmc 0:1 0x3000000 ${kernel_image}; fatload mmc 0:1 0x2FF0000 ${devicetree_image}; bootm 0x3000000 - 0x2FF0000
update_config=if test -e mmc 0 ${configenv}; then if env run loadconfigenv; then run importconfigenv && setenv bitstream_image ${config_dir}${bitstream_image} && setenv devicetree_image ${config_dir}${devicetree_image}; fi; fi;
uenvcmd=run update_config; run mmc_loadbit; run boot_snickerdoodle

[weath...@krtkl.com]

On whichever I/O connector you are using on the snickerdoodle have you either provided a reference voltage (1.2V-3.3V) to pin 3 for that I/O bank or tied pin 3 to pin 1 to use the 3.3V supply that is provided on board?

-Jamil

[ghirma...@gmail.com]

Hey,

Thanks for the speedy reply!

I actually didn't realize I needed to supply a voltage to pin 3 of whichever FPGA bank I was using. 

I was still unable to get any voltages on the pins I selected even after I added a jumper wire between pin 1 and 3 to supply power to the bank I was using. When uploading the GPIO bitstream, I ran both the linux method, and upon bootup method.

Here are the steps I took, specifically when running gpiotest.sh

I pulled up the command line on snickerdoodle, and first uploaded the bitstream using the linux method. Then ran the following commands for the gpiotest examples:

source gpiotest.sh JB1.12 1

I did not do the command

echo 742 > /sys/class/gpio/export

because I was receiving a 

echo: write error: invalid argument

On troubleshooting this it seemed that this may not have been necessary since the gpiotest.sh script actually has a function that does this for me, and appears to have the correct permissions to do so (line 60): 

function export_gpio() {

   echo $1 > $(GPIO_BASE)/export

}

So I'm guessing either something is wrong with how I'm doing the GPIO example, or perhaps its my method of uploading a bitstream using either the linux method or bootup method

[ghirma...@gmail.com]

Quick update:

Turns out my issue is actually with the BreakyBreaky rev3 board I am using! 

I have it connected to the Snickerdoodle rev3, and provided power through breakybreaky by connecting pin 1 to 3. However, my issue was: after successfully uploading the bitstream and running the gpiotest.sh, I'm getting voltage from the Snickerdoodle board (using multimeter to measure the banks on snickerdoodle) but NOT on the breakybreaky pins.

I guess this means its a different issue, so should I mark this one as resolved?

Thanks!

On Sunday, October 2, 2016 at 2:32:37 PM UTC-7, ghirma...@gmail.com wrote:

[weath...@krtkl.com]

Hi, can you document which pins you were probing on the breakyBreaky versus which pins on the snickerdoodle?
One major difference between breakyBreaky rev 3 and rev 4 was that while the breakyBreaky rev 3 pins are correctly marked (pin number 1) the physical orientation that they are in is not user friendly.
We corrected that on rev 4 flipping the connectors around so they perfectly mirror the snickerdoodle and also adding a lot of silkscreen labeling to fully clarify pin position.

Let me know which connector/pin on the snickerdoodle you are probing and I'll send over a marked up image just to make sure it isn't anything else.

-Jamil

[ghirma...@gmail.com]

Hey,

Hopefully this isn't too confusing, but I've attached pictures of the pins I've used

1. GPIOtest Failure.jpg: is the pins I measured when turning on JB1.24 (after running the gpio example). This resulted in no voltage and is based on my assumption that the Snickerdoodle and breakyBreaky rev3 pins are mirrored

2. GPIOtest Success.jpg: is the pins I measured when turning on JB1.24 (after running the gpio example). I figured the pin map out may be mapped in an inverted way, and got lucky that I found the right pins 

Do you perhaps of a link to the breakyBreaky rev3 board pinout mapping? I had trouble finding it in github (closest I found was this from a previous forum post, though it doesn't say the rev version)

[weath...@krtkl.com]

Just closing this off.  Yes on the rev 3.0 breakyBreakys the connectors are flipped and mirrored.  Look for the location of the pin 1 marking (arrow or dot).   I believe this was originally done to ease routing and keep the board down to 6 layers but I realized after the fact that it was completely not user friendly.
The updated rev 4.0 breakyBreaky design was rerouted a few months ago and the silkscreen was also vastly improved.  I haven't released the schematics and layout files yet so as to avoid confusion since we haven't shipped out all the rev 3.0s we have on hand.
Once we start building rev 4.0 breakyBreakys I will release those files to the public gitHub and in the future this sort of confusion will hopefully be avoided.  

We will continue to make our best efforts to make iterative improvements to aspects of the products that are under-performing or not user friendly.

-Jamil