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

[Altera_Forum]

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.

[Altera_Forum]

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..

[Altera_Forum]

--- 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.

[Altera_Forum]

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?

[Altera_Forum]

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.

[Altera_Forum]

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

[Altera_Forum]

--- Quote Start ---  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?   --- Quote End ---   This is my terminal output: U-Boot SPL 2013.01.01 (Jan 28 2015 - 17:56:44) BOARD : Altera SOCFPGA Cyclone V 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 800 MHz CLOCK: DDR clock 300 MHz CLOCK: UART clock 100000 KHz CLOCK: MMC clock 3125 KHz CLOCK: QSPI clock 3125 KHz RESET: COLD SDRAM: Initializing MMR registers SDRAM: Calibrating PHY SEQ.C: Preparing to start memory calibration SEQ.C: CALIBRATION PASSED SDRAM: 512 MiB SDRAM: Scrubbing 0x01000000 - 0x02000000 SDRAM: Scrubbing success with 27 ms SDRAM: Scrubbing 0x00000000 - 0x01000000 SDRAM: Scrubbing 0x02000000 - 0x20000000  So it's ok with SDRAM calibration. Furthermore I've done a simple write/read test over SDRAM address space and it was successful.     --- Quote Start ---  If you try the following, does this work on your custom board?  Code:  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.  --- Quote End ---    I've tried it excepting enabling semihosting (I do it after preloader due to it is unhosted one). Here is output in debugger:  +reset system +stop WARNING(CMD315): Target is not running +set semihosting enabled false +loadfile "C:\workspace\arm\Altera-SoCFPGA-HardwareLib-16550-CV-GNU\u-boot-spl" Target has been reset Loaded section .text: S:0xFFFF0000 ~ S:0xFFFF67A3 (size 0x67A4) Loaded section .rodata: S:0xFFFF67A4 ~ S:0xFFFF87E6 (size 0x2043) Loaded section .data: S:0xFFFF87E8 ~ S:0xFFFF94EF (size 0xD08) Entry point S:0xFFFF0000 Execution stopped at: S:0xFFFF0004 S:0xFFFF0004 40,0 ldr pc, _undefined_instruction +delete All user breakpoints deleted +tbreak spl_boot_device Breakpoint 1 at S:0xFFFF14AC on file spl.c, line 71 on file spl.c, line 81 +run Reloading program Starting target with image C:\workspace\arm\Altera-SoCFPGA-HardwareLib-16550-CV-GNU\u-boot-spl Running from entry point +wait Execution stopped at breakpoint 1: S:0xFFFF14AC In spl.c S:0xFFFF14AC 71,0 { Deleted temporary breakpoint: 1 +loadfile "C:\workspace\arm\Altera-SoCFPGA-HardwareLib-16550-CV-GNU\hwlib.axf" Loaded section .ARM.exidx: S:0x00126694 ~ S:0x0012669B (size 0x8) Loaded section .text: S:0x00100000 ~ S:0x0012661F (size 0x26620) Loaded section .eh_frame: S:0x00126620 ~ S:0x00126693 (size 0x74) Loaded section .ARM.exidx: S:0x00126694 ~ S:0x0012669B (size 0x8) Loaded section .rodata: S:0x001266A0 ~ S:0x0012720F (size 0xB70) Loaded section .data: S:0x00127210 ~ S:0x00127BC7 (size 0x9B8) Entry point S:0x00100040 +set semihosting enabled true Semihosting server socket created at port 8000 WARNING(TAB139): Semihosting was enabled after the target had started running so may not work correctly. Enable semihosting in a target initialization debugger script or with an image symbol instead +start Starting target with image C:\workspace\arm\Altera-SoCFPGA-HardwareLib-16550-CV-GNU\hwlib.axf Running from entry point interrupt Execution stopped at: S:0xFFFF0004 S:0xFFFF0004 LDR pc, ; = 0xFFFF0020 And I need to stop it manually because it hangs. Have you more ideas? ) Thank you for response.    --- Quote Start ---  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.   --- Quote End ---   Thank you, I am waiting for your response )

[Altera_Forum]

--- Quote Start ---  This is my terminal output: <snip> I've tried it excepting enabling semihosting (I do it after preloader due to it is unhosted one). Here is output in debugger:   WARNING(TAB139): Semihosting was enabled after the target had started running so may not work correctly. Enable semihosting in a target initialization debugger script or with an image  <snip>    --- Quote End ---     Try moving the "set semihosting enabled true" before the initial "run" command in the script. This will run the unhosted uboot with semihosting, but this should be okay. If I run on my board with semihosting enabled before the first "run" with an unhosted u-boot this works and directs output to the uart. I also do not see this warning. I believe you need to try to remove the above warning from DS-5 regarding that it may not work correctly.

[Altera_Forum]

--- Quote Start ---  Try moving the "set semihosting enabled true" before the initial "run" command in the script. This will run the unhosted uboot with semihosting, but this should be okay. If I run on my board with semihosting enabled before the first "run" with an unhosted u-boot this works and directs output to the uart. I also do not see this warning. I believe you need to try to remove the above warning from DS-5 regarding that it may not work correctly.   --- Quote End ---   You're right with semihosting enabled and unhosted u-boot. It prints its data to terminal, it's ok. Now there is no warning but CPU fails to 0xFFFF0004 nonetheless :( The interesting thing is all this stuff works on the Arrow board. The major difference is SDRAM type. The other conditions seem to be the same.

[Altera_Forum]

Well, at least the warning is gone. :) 

 Have you tried single stepping through the UART example code instead of running "start"? Since it is receiving an invalid instruction interrupt, I wonder if you see this on the first instruction or if it dies somewhere along the way.   Also, can DS-5 see the external memory locations in the memory window?

[Altera_Forum]

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...

[Altera_Forum]

--- 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?