Forum Discussion
Altera_Forum
Honored Contributor
Honored ContributorNios 2 IDE download verification error
Downloading 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.25 Replies
Altera_ForumHi Jesse,
thanks for your detailed explanation. But in my case, EPCS contains at address 0 a FPGA configuration and behind it a firmware, which is compiled and linked also to address 0 (restart vector) but will be relocated to its original address by a boot loader after restart. But this offset is obviously not taken into account by this verification process which compares against address 0 (as shown above) and aborts debugging due to this assumed error. So what options do I have to debug this firmware ? Mike- Altera_Forum
I've re-thought what I typed above. I stand by most of it, but now that I think about it, MiR, I think there is something funny going on WRT the EPCS controller. I think slacker got it right in the separate thread in the software forum on this issue.
Setting the Nios II reset vector to EPCS should not cause code to be linked to that address (0x0 in your case), because the EPCS loader peripheral has a dedicated firmware rom with the boot loader; it is never linked into the .elf. Further, the EPCS chips themsevles are not ordinary memory-mapped devices such as CFI flash. By contrast, if you were linking some of your software/data into CFI flash I could see the download verification error occuring... ....sorry to be wishy washy about this, its just that something doesn't seem right and nothing should be linked to EPCS like that... - Altera_Forum
yes, I wrote nonsense above. The contents of EPCS is not visible in NIOS address space. It is the epcs-controller located at address 0, which is the restart address. But the problem is still the same.
This is part of my firmware.objdump file:
There is a section .entry located at 0x00000000 (the epcs-controller base address). All firmware is placed in SRAM (base = 0x00200000).Sections: Idx Name Size VMA LMA File off Algn 0 .entry 00000020 00000000 00000000 000000b4 2**5 CONTENTS, ALLOC, LOAD, READONLY, CODE 1 .exceptions 000000cc 00200020 00200020 000001b0 2**2 CONTENTS, ALLOC, LOAD, READONLY, CODE 2 .text 00022d44 002000ec 002000ec 0000027c 2**2 CONTENTS, ALLOC, LOAD, READONLY, CODE 3 .rodata 00017be0 00222e30 00222e30 00022fc0 2**2 CONTENTS, ALLOC, LOAD, READONLY, DATA 4 .rwdata 00002ebc 0023aa10 0023aa10 0003aba0 2**2 CONTENTS, ALLOC, LOAD, DATA, SMALL_DATA 5 .bss 00010280 0023d8cc 0023d8cc 0003da5c 2**2 ALLOC, SMALL_DATA 6 .epcs_controller 00000000 00000020 00000020 0003da5c 2**0
and here is the code placed in section .entry, linked to address 0:SYMBOL TABLE: 00000000 l d .entry 00000000 00200020 l d .exceptions 00000000 002000ec l d .text 00000000 00222e30 l d .rodata 00000000 0023aa10 l d .rwdata 00000000 0023d8cc l d .bss 00000000 00000020 l d .epcs_controller 00000000
This is the code at the restart address, linked automatically to my firmware. So the first dword at address 0 should be: 0x00810014. But when I start debugger without loading software, I can read a memory map at address 0 but find the code of the boot-copier 'epcs_controller_boot_rom.hex'. The code of this <__reset> function above in section .entry can be found at the start of the firmware placed in EPCS behind the FPGA configuration. So the debugger expects this __reset-code at address 0 where the boot-copier resides in ROM. Perhaps this __reset-code is position independent and therefore also linked to address 0 ? I'm a little bit confused what happens. Anybody else ? Explanations welcome. MikeDisassembly of section .entry: 00000000 <__reset>: */# if NIOS2_ICACHE_SIZE > 0x8000 movhi r2, %hi(NIOS2_ICACHE_SIZE)# else movui r2, NIOS2_ICACHE_SIZE 0: 00810014 movui r2,1024# endif 0: initi r2 4: 1001483a initi r2 addi r2, r2, -NIOS2_ICACHE_LINE_SIZE 8: 10bff804 addi r2,r2,-32 bgt r2, zero, 0b c: 00bffd16 blt zero,r2,4 <__alt_mem_epcs_controller+0x4> 1: - Altera_Forum
Mike,
Be sure you're not targeting the EPCS for any code in the IDE. You should locate your code in volatile memory. If you are (already), and you're setting your reset vector to the EPCS controller's onchip memory, then I think you may have discovered a bug... Cheers, - slacker - Altera_Forum
Slacker,
I agree completely. But as you see in the symbol table above, all user code is placed from address 0x00200000 which is the base of my external SRAM. The only code at address 0 is automatically added, due to the fact, reset vector is assigned to epcs_controller. And epcs_controller suddenly got an offset of 0x20 so the linker doesn't see any conflict. I think Altera uses an overlay scheme not considered by the debugging load / verify process. It would be interesting what address is used for __reset in freecks design, where the error occurs at address 0x00800020. Mike - Altera_Forum
I had the same error and it was my byteblaster connector on the Kit which didn't made a good contact. Just push on it and it was solved.
- Altera_Forum
Sorry guys, I found out what was wrong.....I should have rtfm.
The projectproperties were set at the wrong SOPC builder system. Probably there is no in built check on that property. Best regards, Freeck - Altera_Forum
This thread may be long dead, but if you want to disable verification you can hack your nios2-download script to add the argument --no-verify when it calls nios2-gdb-server to actually do the work.
Of course this is not recommended since as Jesse said, if there is a verify failure then that probably means you got something wrong. If you really are doing exceedingly clever stuff (for example with tightly coupled memories which aren't connected to the data master but are initialised from Quartus II) then you could use nios2-elf-objcopy to copy one elf file to another while removing the stuff you don't want to download. Then download the elf file with the unverifiable data stripped out of it. - Altera_Forum
Thanks for the info on "hacking" the verify feature off.
Is it possible that in a future release that this could be a check box option. I would think that this would make it much more useful. In my situation I am more likely to forget that I changed the script for a test and now the verify feature is off for all of my projects than if it was a setting associated with a specific debug set up. Thanks, Jansen - Altera_Forum
Hello all,
This is an old post but this thread seems very relevant to my topic I am re-releasing a custom development board that was running with 5.0(FULL) now with 5.1(Web). I get the infamous: Verify failed Leaving target processor paused Normally, I would also suspect hardware as a first option. However, I switched PCs and re-ran my 5.0(FULL) and my development board is working fine. So Hardware IS NOT ALWAYS A CULPRIT HERE, atleast it does not seem that way in my case. As an extra note, I did have to fiddle with SOPC again so I could have in theory screwed up the hardware. So, in order to make sure I did not do anything wrong I stepped through my port carefully a couple of times. What I did to port 5.0 Full to 5.1(Web) 1. Delete old NiosII Core 5.0 (Licensed) and insert time-limited 5.1 core(Reset my processorrs characteristics : fast, no tightly coupled memory, etc.) 2. Loaded Virgin machine with 5.1(Web) , 5.1(Megacores) and NiosII5.1 eval(time-limited) 3. Had to edit qsf because I had incremental compiles set and Web5.1 does not support. So now with 5.1 (Web) -Recompile worked fine. -Program of device successful Run SW -SYSID verification okay - Get Processor paused message( Verify Failed) Any thoughts? It is very confusing and frustrating to have the 5.0 Full stuff working with no verify failed and have the 5.1 Web fail on the same board! Thanks, -Baycool
