OpenCores
no use no use 1/1 no use no use
problems when using adv_jtag_bridge to download minsoc
by sotusotu on May 5, 2010
sotusotu
Posts: 10
Joined: Sep 16, 2008
Last seen: Sep 7, 2012
Hi all,
I'm testing the minsoc in my StratixIII(EP3SL150F1152) EVK board(http://www.altera.com/products/devkits/altera/kit-st3-dsp.html). The simulation in orksim was ok. But there were still some jtag problems which made me confused. I met with the problem about "Ignoring packet error, continuing...", which was similar with a previous post in this forums, but i could find a solution.
The followings were my steps and some logs. Please kindly give me some hints.
1) use quartus download the minsoc.sof into the FPGA.
2) open one terminal(named A), set adv_jtag_bridge using usbblaster. Here the adv_jtag_brigde uses libftdi compatible mode. If only using the altera usbblaster, the device can not be found. Also I set the INCLUDE_JSP_SERVER, JSP_MULTI_DEVICE_CHAIN and USE_HISPEED to false in Makefile, and set RSP_TRACE 1 in rsp-server.c. Here is runing log:

log1 (2 kb)


3) open another terminal(named B), use or32-elf-gdb to download the uart firmware.Now the problem occurred. So many "Ignoring packet error, continuing..." reported and i had to terminate it. Here is the runing log:

log2 (5 kb)


4) switch to terminal A, the rsp trace information is printed as:

log3 (179 kb)


In Icarus vpi simulation, there also had the same problem. So I failed to download firmware both in simulator and hardware adv_jtag_bridge. An interesting thing was if adv_jtag_bridge usbblaster didn't add the option "-t", the gdb command "target remote:9999" will break at "0x000018dc in _start ()", while not at "0x00000010 in ?? ()". And adv_jtag_bridge vpi will breat at "while(1)".

Jeremy, Nathan and kindly experts, please help me. Thank you very much.

Best regards
charlie


RE: problems when using adv_jtag_bridge to download minsoc
by rfajardo on May 5, 2010
rfajardo
Posts: 306
Joined: Jun 12, 2008
Last seen: Jan 6, 2020
Hi Sotusotu,

I noticed the same problem on the VPI debugging session and from the report of a guy using a usb_blaster.

The key to solve that issue was to:
-change GDB_BUF_MAX back to it's original value of (NUM_REGS*8)+1 in the file rsp-server.c from the adv_jtag_bridge.

I hope that solves your issue,
Raul
RE: problems when using adv_jtag_bridge to download minsoc
by sotusotu on May 5, 2010
sotusotu
Posts: 10
Joined: Sep 16, 2008
Last seen: Sep 7, 2012
Hi Sotusotu,

I noticed the same problem on the VPI debugging session and from the report of a guy using a usb_blaster.

The key to solve that issue was to:
-change GDB_BUF_MAX back to it's original value of (NUM_REGS*8)+1 in the file rsp-server.c from the adv_jtag_bridge.

I hope that solves your issue,
Raul


Hi Raul,
Thanks for your reply.
I had tried your method. But the issue still existed. And the more times of "Ignoring packet error, continuing..." was reported even when executing the "load" command. How did it happen?
Because the Altera main clock is 50MHz, so the CLOCK_DIVISOR in minsoc_define.v was set to 2 to meet 25MHz system clock. Was it faster for the jtag?
Here is the gdb log:
log4 (3 kb)


On the other hand, I use the Quartus Memory Initialization File(.mif) as the embedded firmware for onchip ram. The minsoc can work and the "hello world" was shown on the terminal. So this issue was only a bug of adv_jtag_bridge.

Best regards
charlie
RE: problems when using adv_jtag_bridge to download minsoc
by rfajardo on May 5, 2010
rfajardo
Posts: 306
Joined: Jun 12, 2008
Last seen: Jan 6, 2020
I had tried your method. But the issue still existed. And the more times of "Ignoring packet error, continuing..." was reported even when executing the "load" command. How did it happen?
Because the Altera main clock is 50MHz, so the CLOCK_DIVISOR in minsoc_define.v was set to 2 to meet 25MHz system clock. Was it faster for the jtag?


I only knows from Nathan Yawn the maintainer of the Advanced Debug System that this is:
"The only time I've seen GDB give "Ignoring packet error, continuing" is when a transaction is taking a very long time. 500-600 bytes/sec is usually fast enough, but it looks like yours is moving slower than that. But, I don't have any hard numbers on how slow is 'too slow,' and I don't know GDB well enough to tell you exactly what that error means. It is surprising that the packet error message shows up so many times on a simple command like "set $pc=0x100". How long did you wait for it to complete? "

Everytime gdb wants to communicate with the target and this takes time, after some time it prints out that message. Even if it works out perfectly afterwards the message will be printed in between.

So it is actually no problem, if it really eventually finishes. As you reported yourself I experienced too, that the command set $pc = 0x100, when simulating VPI does not ever finish. Load works fine, even taking long and outputting a lot of those messages.

After the change of the GDB_BUF_MAX to (NUM_REGS*8)+1, the problem was gone:
(gdb) target remote :9999
Remote debugging using :9999
Ignoring packet error, continuing...
0x00000010 in ?? ()

(gdb) set $pc=0x100
Ignoring packet error, continuing...
(gdb) c
Continuing.

You could try again with the simulation and see if it works now. If not, maybe you could re-check the definition and recompile. If the simulation works but your system doesn't, we must wait for further ideas from Nathan himself.

On the other hand, I use the Quartus Memory Initialization File(.mif) as the embedded firmware for onchip ram. The minsoc can work and the "hello world" was shown on the terminal. So this issue was only a bug of adv_jtag_bridge.


This is a very nice thing to do, another guy posted in a thread that he did the same for Xilinx chips, by just adding a include statement with the memory content on the minsoc_onchip_ram_top.v file.

The memory content has been created for all instances of the ram blocks by a modified version of the hex generator included.

If there were a way to generically include such an option to minsoc I'd gladly to it. So I'd be interested in knowing from you how you did it.

Best regards,
Raul
RE: problems when using adv_jtag_bridge to download minsoc
by sotusotu on May 6, 2010
sotusotu
Posts: 10
Joined: Sep 16, 2008
Last seen: Sep 7, 2012
Hi Raul,
Thanks for you suggestion. I found some points to let the jtag download work:
a) the USE_HISPEED must be set to true
b) GDB_BUF_MAX can be (NUM_REGS*8)+1 or (NUM_REGS*16)+1, but can't set to 1024*16
c) wait..wait...Do not lost patience when using gdb debugger. the "load" command needs 5 minutes, the "set $pc=0x100"command needs 8 minutes. ^@^ You should really ignore the message"Ignoring packet error, continuing...".

Even though it could work,i didn't know the reason. Here are some logs:


gdb.log (3 kb)

As to the onchip memory initialization for Altera FPGA, i use a awkward method: Firstly copy the content of uart-nocache.vmem(excluding the address) and paste into a mif file(use quartus tools). Then this file is used to initialize an altsyncram component in minsoc_onchip_ram.v. The attached is the minsoc_onchip_ram code.


Besides, i have a verilog syntax question. what's the difference between
assign be_i = (wb_cyc_i & wb_stb_i) * wb_sel_i;
and
assign be_i = (wb_cyc_i & wb_stb_i) & wb_sel_i;
I can not see the difference, but the last one can not make minsoc work using quartus synthesis.

Best regards
Charlie
RE: problems when using adv_jtag_bridge to download minsoc
by rfajardo on May 6, 2010
rfajardo
Posts: 306
Joined: Jun 12, 2008
Last seen: Jan 6, 2020
Hi Charlie,

the ftdi based usb blaster cable for altera devices has not been optimized for the adv_jtag_bridge yet. It works for now but that's pretty much it. That's the reason it takes so long, 29 bytes/sec is a very bad rate.

Thanks for your logs and insights, it will surely help other people experience the same with the same hardware/cable.

Besides, i have a verilog syntax question. what's the difference between
assign be_i = (wb_cyc_i & wb_stb_i) * wb_sel_i;
and
assign be_i = (wb_cyc_i & wb_stb_i) & wb_sel_i;
I can not see the difference, but the last one can not make minsoc work using quartus synthesis.


The second statement does not work because of the width difference of the variables you are comparing:
be_i is 4 bits width
wb_cyc_i and wb_stb_i are 1 bit width
wb_sel_i is 4 bit width

If you try to do apply an AND gate to wb_cyc_i and wb_stb_i signals it will work ok. An AND gate with input wb_sel_i and the 1 bit width result of the previous operation cannot be done. They must have the same width for that.

The first statement actually would be better represented as:
assign be_i = ( wb_cyc_i & wb_stb_i ) ? wb_sel_i : 4'h0;
The way it is though, works the same, because if the result of ( wb_cyc_i & wb_stb_i ) is zero, the multiplication will be 0, and a multiplication by 1 always results the other operand, wb_sel_i in our case.

Furthermore a multiplication can be made between any signal widths. The result will always be of width equal the sum of the operands widths. Multiplication by width 1 is an exception, since multiply by 1 does actually nothing.

Best regards,
Raul
RE: problems when using adv_jtag_bridge to download minsoc
by nyawn on May 11, 2010
nyawn
Posts: 173
Joined: Dec 19, 2008
Last seen: May 31, 2023
Sorry for the delayed reply, I've been on the road...

Raul told you most of what I know about this problem. I think it's GDB timing out while waiting for a response. But, GDB apparently keeps waiting, and all data is eventually sent, so everything should work if you just wait long enough.

GDB_BUF_MAX in rsp-server.c controls how much data GDB sends in a single packet. So, a smaller number means less data will have to be sent during a given timeout period, and GDB may not time out. USE_HISPEED in the Makefile (and in the hardware) will make adv_jtag_bridge use fewer bits/USB transactions for a particular data transaction, which will also help. 5 minutes for a load is not unreasonable. 8 minutes for a 'set $pc=0x100' seems extremely long to me, though.

It will be some time before I get the chance to update the libFTDI USB-Blaster driver to use high speed mode, at least months. If you want to try it yourself, I think all the information you need is there, in the two USB-Blaster drivers, and I'll be happy to merge it in if you get it working.

Also, you mentioned in your original post that you saw the target stopped at different instruction addresses depending on whether or not you used the -t option on the command line (0x18dc with, 0x10 without). This is because the self-test (which -t enables) uploads a few instructions to memory from 0x0 - 0x10, and runs the CPU through them, stopping at address 0x10.
RE: problems when using adv_jtag_bridge to download minsoc
by sotusotu on May 13, 2010
sotusotu
Posts: 10
Joined: Sep 16, 2008
Last seen: Sep 7, 2012

It will be some time before I get the chance to update the libFTDI USB-Blaster driver to use high speed mode, at least months. If you want to try it yourself, I think all the information you need is there, in the two USB-Blaster drivers, and I'll be happy to merge it in if you get it working.

Thanks Nathan,
It's promising that the libFTDI merges with the Altera and XILINX USB-Blasters, but I have few experiences on the drivers development. If you have new update of the adv_jtag_bridge, I can offer the test case and bug reports. Thank you very much.

Best regards
Charlie
no use no use 1/1 no use no use
© copyright 1999-2024 OpenCores.org, equivalent to Oliscience, all rights reserved. OpenCores®, registered trademark.