- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi to all,
I got a problem while trying to debug a NIOS II created with the toolchain in version 8.0 SP1. It is the regularly referenced verification problem: Verifying 00000000 ( 0%) Verifying 0000DA28 (84%) Verifying 00010000 (99%) Verify failed between address 0x10000 and 0x10027 Leaving target processor paused However I didn't find a solution to my problem. I'm using memory-mapped IOs (like an SPI-Interface) that are created by the SOPC builder as a memory device. I instance it in C like this: volatile hw_TCfgVmtSpi hw_uCfgVMTPic __attribute__ ((section (".Contr_PIC_SPI"))); TCfgVmtSpi being the structure of the region and using the attribute section to place it on the right address. This all works fine with the release version running in hardware. But when debuging, the debugger is trying to initialize all regions (including the memory-mapped IOs). Now there are 2 problems: 1. The verification couldn't work because it's hardware and no memory (should be stated by the volatile) 2. The debugger is initializing on the wrong addresses. This can be seen with an objdump -p: Program Header: LOAD off 0x000000d4 vaddr 0x00000000 paddr 0x00000000 align 2**0 filesz 0x0000cc44 memsz 0x0000cc44 flags r-x LOAD off 0x0000cd18 vaddr 0x0000cc44 paddr 0x0000cc44 align 2**0 filesz 0x0000084c memsz 0x00000de4 flags rw- LOAD off 0x0000d564 vaddr 0x00022000 paddr 0x0000da28 align 2**0 filesz 0x00000200 memsz 0x00000200 flags rw- LOAD off 0x0000d764 vaddr 0x00010000 paddr 0x0000dc28 align 2**0 filesz 0x00001400 memsz 0x00001400 flags rw- LOAD off 0x0000eb64 vaddr 0x00020000 paddr 0x0000f028 align 2**0 filesz 0x00001000 memsz 0x00001000 flags rw- There's a difference between vaddr and paddr for the 3 memory mapped IOblocks at the end (vaddr being correct). Till now everything worked fine since the on-chip memory address range is up to 0xFFFF and the wrong initialization hit real memory. Now the programm mem size increased and the last block cracks the border (0xf028+0x1000 = 0x10028) leading to the error message above. This leads to my questions: - How can I avoid the initialization of the memory-mapped IOs? - Why is paddr wrong/different from vaddr? Many thanx in advance LogicLLink Copied
1 Reply
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I don't think it is a recommended way to access hardware, it looks hard to ensure that everything is placed at the correct address.
You should rather use the IORD/WR macros to access hardware.
Reply
Topic Options
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page