DS-5 debug problem！

[Altera_Forum]

I use the ds-5 to debug ucosii on terasic DE-1 SOC. 

I want to control the FPGA PIO and I add the altera API to do this. But when I debug the program, commands window shows that “Target Message: Could not determine target state” and target consoles window shows that “ERROR 0 returned when checking ACK NCONT_STALL 1”   Could someone tell me what the problem is？

[Altera_Forum]

In commands.txt is visible that address for download program is 0x00100000. 

In Altera CV SoC present onchip 64K from 0, 64K from FFFF0000 and SDRAM from 0x02000000. See and edit your "ucosii.ds" to set appropriate start of image, may be recompile all.

[Altera_Forum]

the ucosii.ds only has two lines: 

stop file "$sdir/ucosii.axf"   and I change it to  stop loadfile "$sdir/ucosii.axf" 0x0xFFFF0000  but still cannot work.

[Altera_Forum]

Need will find 00100000 and change -- may in linker script for compiling .axf, in other Debug Configuration settings... 

Program in this SoC may be loaded in 02000000 ! Project ucosii may be from other board ?  P.S. Zip all and include here -- standard method :)

[Altera_Forum]

The project ucoii downloaded from the Micrium.com and run on the Altera’s Cyclone V SoC Development Kit. 

I can debug the orginal ucosii project on my terasic's DE1-SoC development board,  Now,I want to use the HPS to control FPGA's pio,and I add altera's API to bring up the bridges,just like the HardwareLibs project does. however,this project come up some problems when I debug it on my board.  The first attachment is the orginal project from the Micrium.com. The second attachment is the project with wrong problems. The pdf explain how to running Micriμm’s μC/OS-II kernel on Altera’s Cyclone V SoC Development Kit.

[Altera_Forum]

Both your projects located on D: with SoC EDS and occupy a long time to compiling. 

May not include hard path to includes and compilator tools to EDS project and use external system variable as "set SoC_Dir=D:\Altera\14...". In Embedded Command Shell even exist "SOCEDS_DEST_ROOT" for this puspose and run "eclipse" from console. Your address 0x00100000 is from linker-script "cycloneV-dk-ram-hosted.ld", which used in 166th line of "Makefile" ! In previous version was used only "ucosii.lds" with 64K of "hi" mem FFFF0000, and with adding HWLIB project size exceed 64K and somebody add new region"ram" from this .ld. I change this .ld to "altera-socfpga-hosted.ld" from other example, and in "ucosii.map" not seed 0x00100000 region, only 0x02000000, loadable to DDR correctly. However, in Altera examples meet both "altera-socfpga-hosted.ld" and "cycloneV-dk-ram-hosted.ld", and both work in its projects ! It is uncomprehensible. And after loading ucosii.axf can't stop running in main() -- this symbol is not found, I change init-script to usual for _GNU-example-applications to big "debug-hosted.ds": there present necessary init of DDR with Preloader and then loading of ucosii.axf.

[Altera_Forum]

could you upload the "altera-socfpga-hosted.ld" and "debug-hosted.ds"？ 

I could not fine them in gnu lib. Thanks！

[Altera_Forum]

See all Altera examples in archives and search there! 

And may try simple change FFFF0000 to 02000000 in ucosii.lds.

[Altera_Forum]

I think out good idea -- load any working application from Altera examples in DS-5to stop in main() and use in "Commands" window command to load our image: "loadfile D:\my_experiment\hwlib\Micrium\Software\EvalBoards\Altera\Cyclone-V-Dev-Kit\GNU\Ex-1\ucosii.axf" or "loadfile D:\my_experiment\ucosii\Micrium\Software\EvalBoards\Altera\Cyclone-V-Dev-Kit\GNU\Ex-1\ucosii.axf" and see/debug its in Disassembly window. 

In ucosii.png (see attachment pictures.zip, why .png not supported in XXI century?!! :) is starting point of good application, without hwlib: it starts from FFFF0000 and have at front jump to +38. In hwlib.png is begin of nonworking application with hwlib: Preloader must go to 02000000 always, and there no interrupt handling, only function bodies. I see to FFFF0000 adress (hwlibFF.png), there good interrupt-codes, only if clear many words from FFFF0000 and retry "loadfile", clearing remain ! I change in ucosii.lds adress to 02000000, recompile -- the same problems, first no vectors, adding of HWLIB damage the project ! In Console window I see line "Entry point S:0x0200B230", goto there and near find good interrupt table: hwlibBoot.png. Need will try from "bare" "good" ucosii project and add hwlib files one by one, see results after "loadfile". Or linker keys explore for reorder sections... First command in program must stay B ! And if set PC to 0200B230 (trough Registers, and in Disassembly window context menu command "Set PC to Selection" works successful) and go debug stepping, I see the same "Bare+semihosting" problems: interrupt ask bit CP15_ISR.I is set to 1 after reset (apparently, from DDR ECC in DDR initializing phase in Preloader: GIC has bad reset if pass this inquiry), 4th command in program is "SVC# 0x123456", it handler is absent, etc... Micrium OS may support ARM semihosting emulation ? On site is many pdfs with ARM SoC specific ?

[Altera_Forum]

So the problem is the “cycloneV-dk-ram-hosted.ld” and “ucossii.lds” is conflicting？maybe should change the initial script？ 

 And I wonder that why using the altera‘s hwlib sample application need to enable semihosting？

[Altera_Forum]

You start using Altera examples from d:/Altera/14.0/embedded/examples/software or SoC Design Examples http://www.altera.com/support/examples/soc/soc.html ? 

Hwlib examples usual using printf() to console, which must be sended to host and displayed in DS-5 window. Even if not use printf(), before main() must be initialized stdin and stdout... For this possibility in .ds used commands "set semihosting enabled false" and "set semihosting enabled true". If commenting last command with "#", application not started, as from flash, because system call to host "SVC 123456" not have a handler. Problem is described in previous post -- bad linking .axf result, first ASM command on 02000000 is not "B" and later not lie other interrupts. May be and with address 00100000 all will work -- suddently DDR is mapped to all 4 G of adresses round-robin ? This know Altera Guru, and they is silently :)

[Altera_Forum]

I think the original project uocsii skips the process of loading the preloader,just like the “u-boot-spl.axf” in project hwlib, and runs on the on chip ram. 

I add the hwlib in ucos and exceed the on chip ram limit. So I use the ”debug-hosted.ds“ to load the “u-boot-spl.axf” to initial the SDRAM and other peripherals.but some errors come out when loading the ucosii.axf. is there any method to solve this problem？

[Altera_Forum]

Your region of memory "0x00100000" at first is good ("Loaded section .text: S:0x00100000 ~ S:0x0010E297 (size 0xE298)" is successful), and after "+start" bad image ("Entry point S:0x0010B298") is damage all. 

If you make image ucosii.axf with "Entry point S:0x00100000" or "Entry point S:0x00100040", then running will be ideal. If running was even from 0x0010B298 ("Running from entry point"), Preloader don't know about this. Use Disassembler window to stepping in asm-mode, load your bad "D:\my_experiment\hwlib\Micrium\Software\EvalBoards\Altera\Cyclone-V-Dev-Kit\GNU\Ex-1\ucosii.axf" with "loadfile" command after runned to main() Altera-s HWLIB example, as I describe long ago. If my words is incomprehensible, ask greater ! You must see start of normal application with "B" on begin and your ucosii.axf with function codes at start. Method will be in tuning linker scripts, I don't know there. Or ask UCOS site, may there is solutions.