I have a Cyclone V board with 1Gbyte DDR3L memory connected up to the HPS. I am loading U-Boot through the Preloader using UART0 and YModem transfers from my PC. This all works, and I can see U-Boot at address 0x0100 0000 (start address is 0x100 0040) and all looks well in the debugger. Before it loads U-Boot it also tests the DDR3 memory with a LFSR pattern across 128MBytes of memory. It fills 128MBytes and then checks 128MBytes and there are no errors. In the preloader, I can edit the data at 0x100 0000 (I've tried editting the string at 0x100 0020 or if I've changed the op code I've put it back again afterwards), and the debugger reports that the data has changed, and all is still well.The difficulty arises when I step to U-Boot, ie to address 0x100 0040. At this point the memory window in the debugger suggests that MOST of the address space here has changed, and if I try and change the data at 0x100 0040 back to what it should be it says it can't write to it, and it reads back the value I was trying to change instead. The same thing happens if, having loaded the U-boot image I then just change the PC in the register space to 0x100 0040. What is the HPS doing that it somehow trashes all the DDR accesses that worked perfectly before it started trying to load code from the DDR memory? Is the instruction cache somehow corrupting things? Attached are screenshots of the memory window before we start executing in DDR and after. As you can see, the data has been shuffled! PS I've tried much the same steps using the GHRD on the Arrow SoCKit board and the debugger behaves perfectly well, and allows accesses to 0x100 0040 before and after the PC has jumped there, etc, so it's not just a DS-5 thing.http://www.alteraforum.com/forum/attachment.php?attachmentid=11382&stc=1 http://www.alteraforum.com/forum/attachment.php?attachmentid=11383&stc=1
Not sure what you mean by that - I have my own board, similar to sockit board, with Cyclone V on it. But I think there was a fault on the board I was running, as it works on two other boards. Still not sure how memory can test ok but not run code from it - how can that be a board fault? Anyway, problem solved for now.