Programming Cyclone III (EP3C16Q240C8N) on ARM board

--- Quote Start ---

Its not parallel port related. The code shows its clearly related to serial port communications.

What the codes mean is related to the protocol the serial device uses. For example, elsewhere you will find code like:

data = 0x70; write(com_port, &data, 1); /* TDO echo off */
data = 0x72; write(com_port, &data, 1); /* auto LEDs off */
data = 0x74; write(com_port, &data, 1); /* ERROR LED off */
data = 0x76; write(com_port, &data, 1); /* DONE LED off */
data = 0x60; write(com_port, &data, 1); /* signals low */

Unless you own whatever serial device they are communicating with, just ignore that code.

--- Quote End ---

Thx for the clarification. The fact that they have put comments on all of them and not on the 0x7E made me doubt.

--- Quote Start ---

I haven't looked at the "byte code" player, just the jam player ...

https://www.altera.com/download/legacy/jam/dnl-player.jsp

Cheers,

Dave

--- Quote End ---

mmm I have used byte code player since this what they were explaining in:

http://www.altera.com/support/devices/tools/jam/tls-jam.html?gsa_pos=2&wt.oss_r=1&wt.oss=jam%20stapl

Section Related Documents:

Using Jam STAPL for ISP via an Embedded Processor (PDF) chapter of the MAX II Handbook

So a quick difference between file of each is that the JAM Player have more files then byte code player:

tree jbi_22/code/

jbi_22/code/

├── JBICOMP.C

├── JBICOMP.H

├── JBIEXPRT.H

├── JBIJTAG.C

├── JBIJTAG.H

├── JBIMAIN.C

├── jbiport.h

└── JBISTUB.C

0 directories, 8 files

tree jp_25/source/

jp_25/source/

├── JAMARRAY.C

├── JAMARRAY.H

├── jamcomp.c

├── jamcomp.h

├── JAMCRC.C

├── JAMDEFS.H

├── JAMEXEC.C

├── JAMEXEC.H

├── JAMEXP.C

├── JAMEXP.H

├── jamexprt.h

├── JAMHEAP.C

├── JAMHEAP.H

├── jamjtag.c

├── jamjtag.h

├── JAMNOTE.C

├── jamport.h

├── JAMSTACK.C

├── JAMSTACK.H

├── jamstub.c

├── JAMSYM.C

├── JAMSYM.H

├── JAMUTIL.C

├── JAMUTIL.H

├── JAMYTAB.H

└── makefile.mak

So what I'm seeing from the diff of these files are the same files with add-on. I will use the JAM PLAYER to benefit from the add-on.

thx

Kevyn-Alexandre

--- Quote Start ---

So this 0x7e will be a parallel port specific thing!

--- Quote End ---

Its not parallel port related. The code shows its clearly related to serial port communications.

What the codes mean is related to the protocol the serial device uses. For example, elsewhere you will find code like:

data = 0x70; write(com_port, &data, 1); /* TDO echo off */
data = 0x72; write(com_port, &data, 1); /* auto LEDs off */
data = 0x74; write(com_port, &data, 1); /* ERROR LED off */
data = 0x76; write(com_port, &data, 1); /* DONE LED off */
data = 0x60; write(com_port, &data, 1); /* signals low */

Unless you own whatever serial device they are communicating with, just ignore that code.

I haven't looked at the "byte code" player, just the jam player ...

https://www.altera.com/download/legacy/jam/dnl-player.jsp

Cheers,

Dave

--- Quote Start ---

I'm not sure what source you are referring to (i.e., where the jbistub.c source code comes from),

--- Quote End ---

So I'm using JAM STAPL from there:

http://www.altera.com/support/devices/tools/jam/tls-jam.html

The source code from there:

https://www.altera.com/download/legacy/jam/dnl-byte_code_player.jsp

unzip the exe you will found the file that I was speaking about (jbistub.c)

From source line 244 you can see what I was speaking about.

--- Quote Start ---

but if you are looking at a port that uses the parallel port, you have to realize that the 'classic' parallel port is output only at the DATA registers, and then input is obtained from either the CONTROL or STATUS registers. Those registers need to have their output drivers disabled by basically writing 1's to the port, so that an external signal can drive the pin low. Hence a line like:

write(com_port, &ch_data, 1);

to port 1 could simple be deasserting the contol lines so that the TDO signal can be read.

Just a guess ...

Cheers,

Dave

--- Quote End ---

So this 0x7e will be a parallel port specific thing! I will make some test with or without to see.

thx

kap

I'm not sure what source you are referring to (i.e., where the jbistub.c source code comes from), but if you are looking at a port that uses the parallel port, you have to realize that the 'classic' parallel port is output only at the DATA registers, and then input is obtained from either the CONTROL or STATUS registers. Those registers need to have their output drivers disabled by basically writing 1's to the port, so that an external signal can drive the pin low. Hence a line like:

write(com_port, &ch_data, 1);

to port 1 could simple be deasserting the contol lines so that the TDO signal can be read.

Just a guess ...

Cheers,

Dave

--- Quote Start ---

Porting the Jam player is pretty simple. I use it for programming EPC2 EEPROMs (used with FLEX10K FPGAs), and for programming MAX II CPLDs.

Porting the Jam player basically involves supplying toggle I/O routines for controlling the JTAG pins.

--- Quote End ---

I had more times to check the source code of JAM STAPL and compile it for UNIX. Since I need to port the code for embedded linux board with OMAP3. I configure the MUX pins of the ARM processor to associate to specific GPIO that I will use for TCK,TMS,TDI,TDO.

So now what I need to understand in the jbistub.c from JAM is why :

1- Before each read it does this write of 0x7E:

ch_data = 0x7e;

write(com_port, &ch_data, 1);

THIS mean that 01111110 and since

TCK = bit 0

TMS = bit 1

TDI = bit 6

TDO = bit 7

So TCK = 0, TMS = 1, TDI = 1 and TDO = 0

So why doing this before each read? Is it only specific to parallel port of JTAG specific?

From this document page 9

http://www.altera.com/literature/hb/max2/max2_mii51015.pdf

2- Second question why looping 100 for the read? parallel port specific or JTAG? Maybe a validation to simply be sure to read the value and not missing it because the read is done to fast??? That seem to me a poor way to code this?

for (i = 0; (i < 100) && (result != 1); ++i)

{

result = read(com_port, &ch_data, 1);

}

if (result == 1)

{

tdo = ch_data & 0x01;

}

else

{

fprintf(stderr, "Error: BitBlaster not responding\n");

}

Regards,

Kevyn-Alexandre Paré

--- Quote Start ---

From what I'm reading about JRunner and JAM STAPL is could be possible to code or modify my own version.

--- Quote End ---

Porting the Jam player is pretty simple. I use it for programming EPC2 EEPROMs (used with FLEX10K FPGAs), and for programming MAX II CPLDs.

Porting the Jam player basically involves supplying toggle I/O routines for controlling the JTAG pins.

While this gives you the ability to (slowly) program the FPGA, it does not give you convenient access to the SignalTap II logic analyzer.

One way to look at your system design, is to consider what is needed for operation, and what is needed for debug. In my systems, I have generally used PS and FPP for configuration of the FPGAs, and then plugged a JTAG cable in when needing to debug. For example;

http://www.ovro.caltech.edu/~dwh/carma_board/ (http://www.ovro.caltech.edu/%7edwh/carma_board/)

However, for really tricky bugs that occur infrequently and randomly across multiple boards (eg., on one board out of 100+), plugging a JTAG cable into all of them is not an option. In the new system I am designing, I will have both a 'fast' programming method (FPP) and a debug method (eg., SignalTap II via JTAG). I also need a low- to medium-speed communications mechanism (for control commands) between the host and the FPGA. With these requirements in mind, I'm looking at using the FT2232H as both a USB-Blaster clone (so that Quartus recognizes it), and as a USB-to-parallel communications channel (20MB/s for the FT2232H in synchronous mode). I'm currently working on the documentation/test results now, I'll post it when its done.

Cheers,

Dave

--- Quote Start ---

You'll find part of the information documented with the Altera JRunner project.

Another option is to to take a detour way over JAM STAPL code.

--- Quote End ---

https://www.altera.com/download/legacy/jrunner/dnl-jrunner.html?gsa_pos=2&wt.oss_r=1&wt.oss=jrunner#about

From what I'm reading about JRunner and JAM STAPL is could be possible to code or modify my own version.

thx will keep reading

--- Quote Start ---

You misunderstand. USBIP would run on the ARM processor, and it allows the USB-Blaster USB connection to be accessed from another machine as a local USB port. This allows an x86 machine running Quartus to 'attach' to the USB port on your ARM processor. Quartus then sees the USB device as a locally attached USB-Blaster.

--- Quote End ---

No I completely understand that part. Sorry if I'm not clear, I cannot use another computer or if you prefer we don't want ;) This is a question of maintenance. The embedded device running with the ARM processor should manage/update the software running on the FPGA.

--- Quote Start ---

Because JTAG is slow (and so is PS). If you need an FPGA loaded fast, then FPP is the solution.

There is nothing really 'open-source' about PS and FPP. They just documented methods for configuring an FPGA.

--- Quote End ---

Thx for the clarification.

--- Quote Start ---

I haven't played with the UrJTAG tools. However, that is the site that has the most details on the USB-Blaster protocol. You can use that information to control your USB-Blaster from FTD2XX DLLs or libusb and libftdi.

However, even with that knowledge, you still cannot program your FPGA via JTAG, without the protocol for converting an .sof or .pof or .rbf file into a JTAG data stream. You could reverse engineer that using a logic analyzer though.

--- Quote End ---

hmmmm....

--- Quote Start ---

Not really sure what you need, but you might also be interested in a STAPL player. IIRC, there's some source code available for that.

http://www.altera.com/support/device...m/tls-jam.html

--- Quote End ---

Thx, What I want is a software that can be cross compile on a embedded computer running ARM processor connected by USB blaster OR JTAG to a FPGA that can help me program / flash the .jic, .soft file.

Hope that this is clarifying what I'm searching.

Best Regards

--- Quote Start ---

However, even with that knowledge, you still cannot program your FPGA via JTAG, without the protocol for converting an .sof or .pof or .rbf file into a JTAG data stream. You could reverse engineer that using a logic analyzer though.

--- Quote End ---

You'll find part of the information documented with the Altera JRunner project.

Another option is to to take a detour way over JAM STAPL code.