Honored ContributorDownloading 00800020 ( 0%)
Downloading 00810000 (85%) Downloaded 75KB in 1.6s (46.8KB/s) Verifying 00800020 ( 0%) Verify failed Leaving target processor paused This message appears when I try to start a simple hello world programme , using the standard SPOC, It worked using the previous version of Nios.
Honored ContributorHi,
I had the same problem, and someone told me that the nios-download in version5.0 is the first one that checks the memory content after downloading. So for example loading code to areas where no RAM is will not work, because it is checked now. Also loading code to RAM that is only connected to the instruction master of the CPU will not work, this will not work with previuos versions, but you will have a direct error now. StefaanHonored ContributorI used a standard "hello world" application using the IDE and I used a standard nios solution from Altera. So what should I do next?
Contact Altera? How did you solve the problem?Honored ContributorYes, 5.0 is the first version to verify that the memory contents have been successfully written.
But I need to correct one point. Loading code to a memory which wasn't connected to the data master would never have worked - how could the memory be written by the debugger? You should debug this by creating an objdump and checking that it matches your memory map. You could also try connecting the debugger without doing a download and trying to write to the memory to ensure it is correctly connected.Honored ContributorWombat,
I did some trials with nio2download, and the code that was sitting in a tightly coupled memory was not verified correctly. Adding a second slave to the data master solved the problem. That's why I thought that code in locations only connected to the instruction master couldn't been downloaded. StefaanHonored Contributorfreeck, are you using a hardware reference design, or is it for your own board? Also what memory are you attempting to download to (if you have more than one memory device you may want to try compile the code into another memory with the IDE). If that fails as well then that would help rule out whether it's the memory failing. Another thing to check is that you have all your I/O set properly, and that you have all unused I/O pulled to the appropriate signal (with the Nios II hardware reference designs we set all unused I/O to tristate in the Quartus II device settings page)
Honored ContributorI use the standard Nios dev board for the cyclone, the standard NIOS2 desgign, and a stand hello world application with the IDE,5.0.
All worked fine using the QII-verion 4.2. After installing V5 this error occured.....Honored Contributorfreeck,
The std design for the Cyclone 1c20 does not have any memory mapped to 0x00800020 (it's flash, actually). In fact, most of the designs, I looked through have CFI flash mapped from 0x0 -- 0x7fff..ff. So, my first question would be... exactly what design are you using? ...and, how did you get different designs than I did, in your kit? Cheers, - slackerHonored ContributorI 've just posted the same problem in onother topic .. see topic (http://www.niosforum.com/forum/index.php?act=st&f=17&t=1777)
The messages I get are:Downloading 00000000 ( 0%) (-> this is EPCS)
Downloading 00005000 ( 0%) (-> this is internal ROM)
Downloading 00200020 ( 0%) (-> this is System-RAM, where firmware should run)
Downloading 00210000 (26%)
Downloading 00220000 (52%)
Downloading 00230000 (78%)
Downloaded 247KB in 5.6s (44.1KB/s)
Verifying 00000000 ( 0%)
Verify failed ( -> ERROR )
Leaving target processor pausedThere seems to be some confusion here with regards to downloading and verification. I think Mike's system above shows the issue clearly: When downloading via nios2-download (and therefore "Run" and "Debug" in the IDE), everything in your .elf file is (attempted) to be downloaded to the board. If you have code linked into non-volatile memory (Flash, ROM, etc.), this will be included in the .elf.
However, the download process does not and cannot program flash (such as EPCS chips) or initialize rom -- there are separate facilities for that (Flash Programmer, Quartus' ability to initialize on-chip ROM, etc) -- all downloading can do is write to RAM. Once the download has completed verification should (correct me if I'm mistaken wombat!) simply read-back the contents of memory at all locations specified in the .elf -- this includes non-volatile memories (flash/rom, etc.). On one hand, I can see the confusion this may create. Verification is a great feature to have to verify that RAMs are written successfully, but since the download process cannot program flash (such as EPCS in Mike's example), that can create some confusion. However, from the perspective of ensuring that your application (contained in your .elf file) runs successfully, verifying that all memory contents are initialized to expected values is also important. I should note that the above is heresay based on my understanding of how these tools work (that is, I have not yet reconstructed this exact experiment on a board in front of me). A great way to verify this (no pun intended) would be to take your compiled application, program any flash memories, re-compile in quartus (if you have on-chip ROMs that need their initialization .hex files refreshed), and then try the download/verify operation again. By contrast, if there is an easy way to not link data into your .elf that is destined for the EPCS controller, that may also be feasible.Honored ContributorI think this will keep coming up. I agree that this is a nice feature, but it would be a whole lot better if there was a check box as part of the debugging options that enabled/disabled the feature. As such I have already made a Support Request for the feature.
The problem is always going to be that when I want test a quick change why should I be forced to write to FLASH or create a special elf file that doesn't have the sections to run a quick test. Just my 2 cents.
