Need help with debugging HPS

[Altera_Forum]

I need help with debugging SoC because I've been stuck on this point for nearly a week. 

 In the past I worked extensively with FPGAs and microprocessors, so I have experience both in hw and sw.  So far I always used FPGAs with soft processors like Nios, but now I want to move to SoC. Then I bought a Terasic DE0-Nano SoC board and I could successfully use it, following the main tutorials and examples.  I can configure FPGA with my design and I could run a Linux or baremetal application in the HPS. The problem came when I tried to add hwlib to HPS in order to access the FPGA part. In the FPGA I use the ghrd reference design, with minor changes: I actually added only a bit of hdl code to blink a LED. In the HPS I'm trying to load the standard baremetal Hello-world ARMCC application. Following the procedures I found in Altera wiki, forum and on rocketboards.com I built the preloader from Qsys handoff files and tried to connect to hps for debugging. But I always get an error and the arm core seems to get stuck somewhere before reaching the breakpoint on spl_boot_device function, as defined in preloader.ds. I cannot get any output log from the jtag uart as well.  I followed the advice in the sticky thread (https://alteraforum.com/forum/showthread.php?t=47099) and I found that when I can set the rstmgr registers to zero via JTAG I actually can access the Qsys peripherals (i.e. manually turn LEDs on and off). Anyway there are still two problems: - I say 'when I can set' because in most cases the rstmgr (and many other registers) show up as 'unavailable' in the debugger, so I can't modify them - even when I set the registers in the correct state and when hps can apparently access FPGA side, neither the preloader nor the application work. What concerns me is the fact the hps behaviour seems very unstable: starting with the board powered off and performing exactly the same steps, leads each time to a different result. For example one time all the hps registers are unavailable; the next try I can access them, set rstmgr and access the bridges and peripherals; sometimes I have situations where only SOME REGISTERS are available.  I also point out another strange fact I can't explain: if I create a simple hello world application on the same ghrd FPGA configuration it works: I can see the 'Hello world' printout in the debugger console and afaik the hps always boots and run fine. If I add the hwlib includes to the project, even if I don't use any of them, I can get no more output from the console and the hps seems to hang like I described above.  Thank you in advance for any advice

[Altera_Forum]

I add some extra information to the above post. 

 I use Quartus Prime 17.1 and DS-5 Intel SoC FPGA Edition V5.27.1  The following is the output log I get when I try to connect the debugger to the hps. Note 1: As I said before, from the jtag uart port I get no output. Note 2: I added the grayed set var lines to the automatically generated script, in the hope they could avoid the hps hang, according to the advices I found in the fourm, but they have no effect.   Connected to running target Altera - Cyclone V SoC (Dual Core) on TCP:localhost cd "C:\DS-5 Workspace" Working directory "C:\DS-5 Workspace" source /v "C:\intelFPGA\17.1\embedded\ds-5\sw\debugger\configdb\Scripts\altera_target_check.py"  No SYSID registers could be found. Has a peripheral description file been supplied?  source /v "C:\FPGA_Q17\cv_soc_devkit_ghrd\software\spl_bsp\preloader_cr.ds" +reset system +stop Target has been reset Execution stopped in SVC mode due to a breakpoint or watchpoint: S:0x00000000 S:0x00000000 LDR pc,[pc,#24] ; [0x20] = 0xA8 WARNING(CMD315): Target is not running +wait 5s +set semihosting enabled 0 +loadfile "$sdir/uboot-socfpga/spl/u-boot-spl" 0x0 Loaded section .text: S:0xFFFF0000 ~ S:0xFFFF7093 (size 0x7094) Loaded section .rodata: S:0xFFFF7094 ~ S:0xFFFF8C21 (size 0x1B8E) Loaded section .data: S:0xFFFF8C28 ~ S:0xFFFF9AFB (size 0xED4) Entry point S:0xFFFF0000 +set debug-from *$entrypoint # Set start-at setting to address of $entrypoint +start  Starting target with image C:\FPGA_Q17\cv_soc_devkit_ghrd\software\spl_bsp\uboot-socfpga\spl\u-boot-spl Running from entry point Execution stopped in SVC mode at S:0xFFFF0000 In start.S S:0xFFFF0000 39,0 _start: b reset +wait 5 +delete All user breakpoints deleted +tbreak spl_boot_device Breakpoint 2 at S:0xFFFF1498 +set var $Peripherals::$rstmgr::$rstmgr_permodrst = 0 +set var $Peripherals::$rstmgr::$rstmgr_per2modrst = 0 +set var $Peripherals::$rstmgr::$rstmgr_mpumodrst = 0 +set var $Peripherals::$rstmgr::$rstmgr_brgmodrst = 0 +set var $Peripherals::$rstmgr::$rstmgr_miscmodrst = 0 +wait 2 +set var $Peripherals::$sdr::$sdr_ctrlgrp_fpgaportrst = 0x00003fff +set var $Peripherals::$sdr::$sdr_ctrlgrp_protportdefault = 0 +cont +wait 2 ERROR(CMD360): # in C:\FPGA_Q17\cv_soc_devkit_ghrd\software\spl_bsp\preloader_cr.ds:71 while executing: wait 2 ! Wait for stopped timed out ERROR(CMD656): The script C:\FPGA_Q17\cv_soc_devkit_ghrd\software\spl_bsp\preloader_cr.ds failed to complete due to an error during execution of the script wait

[Altera_Forum]

I don't like to answer to my own post, but after struggling one more day with the hardware and digging in the forum I eventually found a way to solve the problem. 

I'm still not 100% sure everything is ok, but at least I can now run my baremetal application, blink the LEDs and read button status.  I write here FYI the main points which fixed the problem; I hope this could help someone else.   1. Until this morning I tried to operate the DE0-Nano with the supplied SD card or with no card inserted at all: I was persuaded the latter should be the correct configuration. Then I found this thread (https://www.alteraforum.com/forum/showthread.php?t=56558) which suggested there could be is a hps boot problem when no SD card is connected; on the other hand the boot provided by the original SD card image (with Linux OS or whatever) brings the hps in a state not compatible with a baremetal application (I guess it activates a watchdog or any other OS specific feature) So I removed the supplied SD card and replaced with a blank one. Now the system is stable and I can load my application without errors.  2.  The baremetal reference code I'm using includes "alt_printf.h" among the other hwlib related header files.  I didn't investigate the reason, but including this .h file prevents the debug printf output to show on the app console panel.