Honored Contributor
Honored ContributorThis is the message I just sent to my local FAEs.
============== Hello All, I wanted to make you all aware of a problem that I have found that has plagued us for months here at my company and the workaround for our particular application. To refresh the memories of the Altera folks on this post: We are running a custom board with 6 Altera FPGAs. Five are of the same type and one is a GX25 that performs demultiplexing of input signals. The 6 FPGAs and a CPLD are on a JTAG chain for the purpose of debugging. I happen to be running on a machine that is still running Quartus 4.2 SP1 with NIOS2 V1.1 SP1. I am not sure if this happens on a 5.0 machine. For months now we have been battling a message from the NIOS IDE that states: === There are no Nios II CPUs with debug modules available which match the values specified. Please check that your PLD is correctly configured, downloading a new SOF file if necessary. === The latest problem was happening this morning when I was trying to run code on one processor and debug code on another. What I would do is power on the board, take all the processors out of reset, using the Quartus Programmer I would scan the device chain, choose appropriate files for the two devices I want to use and program via USB Blaster V2. There are no problems with this step. When I scan the device chain I see the devices listed as follows: 1) CPLD 2) Controller FPGA 3) Processor 1 4) Processor 2 5) GX part 6) Processor 3 7) Processor 4 I happen to be programming parts 5 and 7 with the programmer. I move to the IDE which has a project that contains both ELF files that I would like to run. In the configuration to load the GX part (the one that just needs to run and not be debugged) I set the project, elf file, .ptf file, processor, JTAG cable (USB Blaster), I tell it not to use any NIOS Uart ports and I would choose the processor that matches the part (i.e. GX). The list of processors on the “Target Connections” tab of the “Run Configuration” looks like: 1) Controller 2) Processor 1 3) Processor 2 4) GX part 5) Processor 3 6) Processor 4 Consequently, I would choose part number 4 here. I kept getting the message that I stated above. However, if I chose to do the following from the command line: === nios2-download -d 5 -c USB-Blaster -r application.elf -g --debug === everything would download and run ok. The same problem happens when trying to download code to “Processor 4” via the IDE (same message as stated above)…and the same workaround is valid (using nios2-download for a different application and different device for the -d switch). What I’ve always wondered about is why the device numbers in the IDE never matched the ones in the Programmer window. Well, it turns out that if I tell the IDE to load to device 5 (i.e. Processor 3 as stated above), regardless of the fact that the device part is different from the part I know I’m trying to program, things work fine when I download to the GX part via the IDE. The IDE seems to be scanning the chain, missing the CPLD and thus not including it in the IDE window when the chain is refreshed in the Target Connections tab, and assigning part numbers that are different from those used by the programmer. But when I choose the same part number that was used by the programmer (again, device 5 regardless of part type listed in the Target Connections tab) I can program the correct device. After I do this, I can program Processor 3 by choosing device 6 in the IDE and debug it with no problems at all. Again, device 6 from the programmer is Processor 3 and I had to fake out the IDE. This didn’t happen when we would run on one processor at a time. We would ask the run configuration to choose the appropriate device and the IDE would comply. But if we ever chose to select the device in the Target Configuration tab or when we download .sofs to more than one processor we would run into this problem. Again, I am not sure if this is an issue with V5.0 of the IDE but it is something to be aware of.
