Mity CPU Platforms » MitySOM-5CSX Altera Cyclone V

Hi Jack,

We have not seen this issue yet. If you power cycle the board did this issue still occur?

Dan

Hi Dan,

The same issue still occurs after power cycling.

I'm wondering if it's a hardware issue.

Jack

Hi Jack,

Please check the MSEL dip switches. These should be set to FPPx16 or FPPx32 for the FPGA Manager to be able to load the FPGA. Those pins are read at power-on. MSEL details can be found in:

Table 7-2 of:
http://www.altera.com/literature/hb/cyclone-v/cv_52007.pdf

Table 13-1: Configuration Schemes for FPGA Configuration by the HPS:
http://www.altera.com/literature/hb/cyclone-v/cv_54013.pdf

Note: The FPGA manager supports a data width of 32 or 16 bits. When configuring the FPGA fabric from
the HPS, Altera recommends that you always set the datawidth to 32 bits. For partial reconfiguration,
the 16-bit data width is the only option.

The Table 13-1 is a bit messed up in the current version of the document. An older image of that table can be found on the Wiki:
http://support.criticallink.com/redmine/projects/mityarm-5cs/wiki/Configuration

What MSEL setting are you trying to boot with?

Thanks,
Adam

Hi Adam,

I'm not sure what the default positions for the MSEL or which of the switches on board are for the MSEL. So here's a picture.

Thanks,

Jack

Hi Dan,

Regarding the uboot procedure, I have never worked with uboot before and the instructions on rocketboard is not very specific as to how to set it up. Could you provide some help on this please?

Thanks again for all your help!

Jack

set fpgaload "fatload mmc 0:1 0x2000000 fpga.rbf;fpga load 0 $""{fpgadata} $""{filesize}" 

This will set a marco for loading the fpga. It will expect an rbf file to be named fpga.rbf in the FAT partition of the SD card.

Running saveenv after will save this marco so it can be used after a reboot.

After the macro is set and the rbf is on the FAT partition, run

run fpgaload

This will now load the fpga. If the FPGA program LED turns off then the FPGA was successfully programmed.

Dan

Hi Dan,

The Linux OS on the board doesn't have run and saveenv. I tried to update it, but it doesn't have the apt-get command either.

Cheers,

Jack

Hi Jack,

This needs to be run during uboot, which you get to by pressing any key during the first 5 seconds of start up. If you are able to load it through uboot then that should factor out a hardware issue.

Dan

Hi Dan,

I got an error: Failed with error code -1.

Jack

was this from the run fpgaload?

Yes

Is the following the full error you received?

altera_load: Failed with error code -1

I'm trying to trace where in the source this error is coming from.

Dan

correct

Looking through the uboot source code it seems that the HPS is not able to set the FPGA into a reset mode. Which could possibly be a hardware issue. One last test is if you have an HSMC board connected, unplug it and try to load the FPGA again. If that doesn't work then the board would need to be returned for an RMA.

Dan

Your MSEL is currently 00000. Try changing S100-position3 to OFF to get an MSEL[4:0] of 00100. This will change the power-on reset delay to Standard instead of Fast.

To read the switch settings, note the white labels in silkscreen on the board. The order represents the switch positions and there is a "HIGH" note to indicate which switch position represents a '1'.

Could this be a OS issue that's causing it?

Can some one direct me the exact link where I can download the img file?

Jack

Currently I do not believe that is the case, seeing as this problem is happening in both uboot and linux.

Have you tried programming the FPGA without anything else plugged in (such as a HSMC card) and setting the MSEL like Adam advised?

Which img file are you referring to? If you are referring to the SD card image, it is available on the virtual machine that was shipped with the dev board. It is located at: /home/user/projects/outputs/sd_image_mityarm_5csx.bin

Dan

Hi Dan,

I did what Adam suggested and it made no difference. I tried it without anything plugged in and still nothing.

Jack

Hi Jack,

I'm not sure what else to try other than trying to program the FPGA through a JTAG pod, which I believe you said you don't have, or sending it back for an RMA.

Dan

Hi Dan,

I had similar problem last week. After two week I tried to run my development board loading the FPGA with JTAG and using Uboot.
JTAG was not able to connect and with Uboot the return message was:

altera_load: Failed with error code -1

After two hours I've discovered that the problem was the discharged battery connected to +3V_VBAT pin of the EVB SOM connector.
The battery is for the backup of security key registers. The pin must be always connected to a power source.

I've changed the battery and all run again.

Max

Max,

Thank you for posting that.

You are correct that if VBAT is too low the module will either not boot at all and/or will not allow the FPGA to be programmed. We believe that on earlier development kits the ESD bags may have contacted the battery terminals on the bottom of the board and caused some amount of premature discharging. We now use some Kapton tape to cover these terminals to help prevent such discharge.

In the newest module designs we have added a diode-or circuit to the VBAT input which will allow the module to boot in the event that the RTC battery has failed.

We will post an VBAT/RTC wiki page to cover these concerns and apologize for the amount of time it took to determine the cause in your case.

Thanks,

Alex