Verify failed between address 0x80000 and 0x8FFFF

Hello,

Do you have system ID included in your SOPC design ?

Adam

Hi, No idea about sysid...but you can investigate it...anyway there is a menu in EDS to say that is not needed to check it ...to avoid any problem with sysid...

In my experience, if I remember well, I've seen this happening only when ram is not working properly...let me suppose...0x80000 is a ram address where your application is linked to???

Usually you link an application to start from base address of a "ram" inside your system...but before starting the processor the tools check what you have downloaded....

Is the link address correct?? Is the ram working??? If you have, actually, any problem with ram...insert an onchip ram in your design...build the memtest small template that comes with eds and check external ram for real problems...

Carlo

file,

with

--------------------------------------- Posted through

at

, l

Not sure about the board you're using, but on my DE0 board, the code defaults to going into the largest RAM section (which of course is the SDRAM). So, if you're testing from 0x800000, you'll be overwriting the code itself. The memtest.c that comes with Quartus 10.1 allows you to specify a start and end address to test, so I was using 0x820000 to

0xf00000. Note that the top-end of ram is used for the stack, so you need to not overwrite part of that too.

If you need to test all your ram, you'll need to set up an 8k+ on-chip RAM, and edit your BSP's linker-script to place the code in the smaller on-chip RAM. Then you'll have all the SDRAM to play with.

Simon

I had similar problem once. Even with "don't check sysid" feature marked, I couldn't download app. As I remember with Q10.0 or similar. What is located in this area from hardware side ? Program ram, flash , IO ?

Adam

Uhmmm..strange...10.0 bug???

?

This is the best question...what is starting from 0x80000 and where do you link your sw...said in other way...which address your software starts from??

As somebody suggested...you cannot test a piece of ram where you are running your test code...pay attention....

Anyway in my opinion this is not the case....eds is not able to download correctly the code...if this is not related to sysid (I never experimented that problem so I cannot say) it should be related to memory problems or link address problems...check it..

If you are using a demo board with a standard project..I tend to exclude ram problems...the board and the netlist have been already checked before selling ...if you are using custom hw...ram could not be working...if you are using custom project..check againg your .sopc and, eventually, timing constraints for the ram...that can be the problem...

Carlo

--------------------------------------- Posted through

I ran into this myself earlier today while I was trying to debug DMA. The problem (in my case) was that I'd forgotten to include the PLL that offsets the SDRAM (off-chip) clock from the cpu (on-chip) clock. The SDRAM would work intermittently, sometimes the download would succeed, sometimes it would fail.

Adding the PLL solved this for me, although it didn't help me get DMA working :( I had to jump to Quartus2 v11 to get the DMA to successfully transfer data - what appeared to be the same design in

10.1 didn't work for me.

Simon