ERROR(CMD16-TAD59-NAL63): ! Failed to load "helloWorld.axf"

Hi Stephen,

Thanks for your response,

My compiler is Arm Compiler 6 and after your response, I have created a scatter file to download the code to the on-chip ram whose base address is 0xFFE00000 and end address is 0xFFE3FFFF. 

**********

OCRAM 0xFFE00000 0x40000

{

APP_CODE +0

{

* (+RO, +RW, +ZI)

}

ARM_LIB_STACKHEAP 0xFFE37000 EMPTY 0x8000

{}

}

************

the code is compiled with my scatter file. In console it says my app is loaded to the 0xFFE00000 however it didn't get me to the main to debug it. Connection says "waitForTargetToStop" "4 pending" I don't know what to do from this point. Could you please help me about that?

I have posted a few posts on Intel's forum however they are still waiting to be responded. I need to make a progress that is the reason for me to ask on this post. I'd be glad, If you can help me to download and debug a simple helloworld.axf to the board.

Best Regards,

Balerion

Hi Balerion

Your scatter file looks ok.

It sounds like your code is hanging somewhere in the C library startup code, and is never reaching main().
This could be for a variety of reasons, such as an unexpected exception occurring, the processor starting in the wrong initial state, or a problem with semihosting.

To debug the issue, in the Debugger tab, select "Debug from entry point" instead of "Debug from main".
You can then step through the code to see where it is failing.

Do you see the processor stopped in EL3, or some other EL?

Try setting a breakpoint on __rt_entry with: break __rt_entry
Does it hit that breakpoint?  If so, do the same for __rt_lib_init.

Hope this helps

Stephen

Hi Stephen,

Thanks for your response. The processor stops in EL3. Since I load my code to 0xFFE00000. It first stops there, then I set breakpoints to __rt_lib_init and __rt_entry. The processor also stops there. After all, the processor gets stuck. I don't know the reason but after all it didn't response my debug commands.

Best Regards,

Balerion

I realized that the execution get stucks at running on __rt_lib_init_atexit_1.

In console it says

"Execution stopped in EL3h mode at breakpoint 6: EL3:0x00000000FFEE00024

In __rt_lib_init_atexit_1 (no debug info)

EL3:0x00000000FFEE00024 BL _initio ; 0xFFE003DC "

Best Regards,

Balerion

Hi again Stephen,

I found out that in dissassambly mode I executed the program step by step by pressing step in button. Interestingly, it worked and printed hello world message to the console. However, when I run __rt_lib_init_atexit_1 by pressing run button it got stuck running, the core don't respond after this point. My debug commands don't work.

Do you know what causes this?

Best Regards,

Balerion

Hello Stephen,

Thanks for your response. I am currently able to download and debug the code to the HPS. However, there seems to be a problem with my memory. Because I am not able to access the peripherals for example I couldn't view the uart0 base address from memory browser. Interestingly, I can see the downloaded code in SDRAM or OCRAM. I also couldn't access some other peripherals too. Do you have any idea about this? If so, I'd be glad to hear that. Because I need to use Uart peripheral for my application.

Best Regards,

Balerion

Hi Stephen,

Thanks for your response, I tried EL1N, EL2N and EL3. It did not show me those addresses in Arm Debugger'd Memory tab. However, Interesting thing is that I can define a pointer to those addresses (Clock manager base or Uart base) and read and write to the registers. I can also see the registers in Registers tab under AArch64->Peripherals->i_uart_0. I guess the problem is no more with the dev kit but debugger or IDE. I am not even be able to use Debug's Memory tab and Add Memory Monitor. 

Best Regards,

Balerion

Hello Stephen,

I tried to reduce 1024 to 4, 32, 40 etc. and I saw the memory addresses in memory tab. But I realized that I couldn't write to registers in uart0, uart1, i2c and some other peripherals too. I can only read them, but I have RW access to those registers. I tried to read and write to clock manager block's registers and I am able to RW them. Then I tried to change the registers of uart0 from memory view not in my code, I changed them. So, It seems that I am not able to write to registers of some peripherals in my code while I can change them in memory tab. Do you know what may the problem be here? If so, I'd glad to hear it. Otherwise, I'm going to ask this in Intel's forum however, there are some posts of mine which are still waiting to be responded. 

Best Regards,

Balerion

Hi Balerion

Glad to hear that you can now access the peripherals via the debugger :)

It is puzzling that you can read/write the clock manager block from C code, but only read (and not write) the UART.

Peripheral registers are sometimes sensitive to the width of the memory access by the processor.  For example, a 32-bit peripheral register might only be accessible with 32-bit read/write instructions (LDR/STR), and 8/16/64-bit accesses won't work.

Sorry, I don't know the size of the UART registers in your hardware, or whether they have access size constraints like this.  Suggest you check which load/store instructions are being generated when you compile your code.  You can do this by setting a breakpoint in your code just before you try to write to the UART, then open the Disassembly view.  You can then single-step at assembly level through the code (press F10 to toggle between single-stepping at instruction level and source-code level) and check whether it is working correctly.

If the UART registers are sensitive to the width of the memory access by the processor, then you might need a cast in your C code to force a particular access size load/store instruction to be generated, e.g. "*(short *)" for 16-bit LDRB/STRB.

As I mentioned before, you can also use the Debugger CLI to force a particular access size read/write, which can be useful for testing.

Also check that you have marked the peripherals as "volatile" in your C code.

Stephen

Hi Stephen, 

Thanks for your response. I am currently able to RW to peripherals. That is why I wanted to send a byte from Uart0. I configured its baud rate, parity, stop bit and fifos. Then, I tried to send data from uart but there occured a problem. In console it says "NCONT ERROR in ACK for access 0: ACK = 0x01" Since, I programmed my qspi flash with .jic file which contains .sof and .hex(First stage bootloader) that is why u-boot is writing something from uart0 to my terminal. I don't know what the problem here is. Do you have any idea about it?

Best Regards,

Balerion.

Hi again,

Sorry, I have no knowledge of the peripherals on the Intel platforms.  You'll need to ask on the Intel forums.

Stephen

Hi Stephen, 

Thanks for everything. This post can be marked as solved.

Best Regards,

Balerion