Hi, I have 2 boards with Cyclone V SoC. One is the Arrow SoCkit and the other is our custom one. There are DDR3 SDRAM installed in Arrow and LPDDR2 SDRAM installed in custom board. I've made preloaders for both boadrs. HPS boots from FPGA portion of the devices. Both HPS started normally, I see preloaders' info in terminals. Then I try to load simple application to SRDAM and execute it via DS-5 debugger. With Arrow board it's alright, but with custom board I've got some issues. Actually the application is loaded but when I try "start" or "run" command in debugger the HPS fails to reset. "Helloworld" example running in HPS OCRAM works for both boards. In this example I've also tried to read/write some addresses in SDRAM (for DDR3 and LPDDR2) and it's ok. I wonder to know how to fix it. Thanks.

If you used the Qsys system that targeted the Arrow board and used it for your custom board did you remember to change the SDRAM to LPDDR2 and modify the timings? If not then that's probably what's wrong. After you generate the system you should also run the I/O constraints script for the SDRAM controller to make sure the necessary constraints are added for LPDDR2. For information about running the SDRAM constraints you can look at the Uniphy user manual which applies to the HPS memory controller as well. If you forgot to make those changes in Qsys and your custom board has a different pinout you might need to change the HPS pin muxing options to match your board as well as the pin assignments and constraints in the Quartus project..

--- Quote Start --- If you used the Qsys system that targeted the Arrow board and used it for your custom board did you remember to change the SDRAM to LPDDR2 and modify the timings? If not then that's probably what's wrong. After you generate the system you should also run the I/O constraints script for the SDRAM controller to make sure the necessary constraints are added for LPDDR2. For information about running the SDRAM constraints you can look at the Uniphy user manual which applies to the HPS memory controller as well. If you forgot to make those changes in Qsys and your custom board has a different pinout you might need to change the HPS pin muxing options to match your board as well as the pin assignments and constraints in the Quartus project.. --- Quote End --- Thank you. This has been already done. LPDDR2 has been initialized successfully. The problem is in application running from entry point I think. And it is platform dependent.

I've tried to load unhosted preloader manually to both CPUs via debugger: set semihosting enabled false loadfile "C:\workspace\arm\Altera-SoCFPGA-HardwareLib-16550-CV-GNU\u-boot-spl" run stop It executes for both boards and SDRAM is accessible. Further I've loaded hosted application this way: set semihosting enabled true loadfile "C:\workspace\arm\Altera-SoCFPGA-HardwareLib-16550-CV-GNU\hwlib.axf" start For Arrow board it's ok, but for custom one CPU hangs in 0xFFFF0004 region (or about, e.g. 0xFFFF0020) and nothing happens. Preloader settings are the same. QSys projects differ by SDRAM controller only. I've also tried to fully recreate and rebuild preloader for troublesome system, it doesn't help. In what could be the problem?

I'll ping the software folks on my team to see if they have any ideas, unfortunately I haven't run much software on the SoC yet to know if something else needs to be done. You should hear back tomorrow, if not post here to send me a reminder.

If you try the following, does this work on your custom board? set semihosting enabled false loadfile "u-boot-spl.axf" 0x0 set semihosting enabled true delete tbreak spl_boot_device run wait loadfile "hwlib.axf" 0x0 start This will wait for uboot to reach a safe location in the code. The 0xffff0020 location is the undefined instruction vector, so it could be possible that the LPDDR2 memory is corrupted or has some timing issue. Can you copy the output from u-boot as well? Does it report that calibration has passed (see below as an example) on your board? CLOCK: EOSC1 clock 25000 KHz CLOCK: EOSC2 clock 25000 KHz CLOCK: F2S_SDR_REF clock 0 KHz CLOCK: F2S_PER_REF clock 0 KHz CLOCK: MPU clock 925 MHz CLOCK: DDR clock 400 MHz CLOCK: UART clock 100000 KHz CLOCK: MMC clock 50000 KHz CLOCK: QSPI clock 370000 KHz SDRAM: Initializing MMR registers SDRAM: Calibrating PHY SEQ.C: Preparing to start memory calibration SEQ.C: CALIBRATION PASSED SDRAM: 1024 MiB SDRAM: ECC Enabled

DS-5 debugger "run" or "start" option lead HPS to reset

11 Replies

Altera_Forum
Honored Contributor
10 years ago
--- Quote Start ---
It seems to me I've fixed this issue :)
The pitfall is linker script: *.ld. The default linker script by Altera from Quartus directory assumed there are 1024 Mb of memory installed on the board. But there are only 512 in our custom board so debugger probably doesn't allow to start application which was linked for 1Gb SDRAM. I've customized linker script for myself:
MEMORY { boot_rom (rx) : ORIGIN = 0xfffd0000, LENGTH = 64K oc_ram (rwx) : ORIGIN = 0xffff0000, LENGTH = 64K /* Need to have 64bytes available before start of program, to store the mkimage header */ ram (rwx) : ORIGIN = 0x100000 + 0x40, LENGTH = 511M - 0x40 }

and it starts work! The real problem is that it's not obvious at all. Maybe for ARM guru, but not for RTL designer! The lack of programming documentation gathered in UG is the major issue I think...
--- Quote End ---

Hi, I am working on the same issue as well, but wasn't able to find documentation to explain the memory parameter. The example provided by Altera was a simple Hello World program that I managed to get it to work, but once I included the GPIO and QSPI features into the program, the UART console does not print out message. I realize the binary output file is larger because of added in features, so does the mkimage header require a larger available memory before start of program? I just wonder if you know anything that can help resolve my issue?

Forum Discussion

DS-5 debugger "run" or "start" option lead HPS to reset

11 Replies

Recent Discussions

Is VCCPD = 3.3V and VCCIO = 2.5V allowed on an Arria V?

Agilex5 NSATUS signal behavior at power up.

TSE MAC+PCS (SGMII, Cyclone 10 GX): mdio_out/mdio_oen never toggle, no matter what I write

Cyclon 5 tampering protection bit

10CL040YF484 Programming fails