Hi all,
I am working on Agilex-7 SoC Dev-Kit and currently I'm facing a problem while trying to debug a simple hello world app. The error is "ERROR(CMD16-TAD59-NAL63): ! Failed to load "helloWorld.axf" ! Download of 145.536 bytes to address EL3:0x0000000000008000 failed while writing block of 4.096 bytes to address EL3:0x0000000000008000"
Could you please help about that?
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?
Hi Balerion_initio is the C library start-up function that opens stdin, stdout and stderr for semihosting.I suspect that semihosting is not being enabled in the Debugger.The Debugger enables semihosting automatically if either symbols "__auto_semihosting" or "__semihosting_library_function" are present in an image, and the symbols for the image are loaded into the Debugger. Arm Compiler for Embedded 6 adds "__semihosting_library_function" automatically to an image at link time if that image uses any semihosting-using functions.
developer.arm.com/.../Working-with-semihosting
Are you loading debug symbols into the Debugger? This can be done with e.g.add-symbol-file /path/to/helloWorld.axf
developer.arm.com/.../add-symbol-file
Alternatively, you can enable semihosting manually with:set semihosting enabled on
developer.arm.com/.../set-semihosting
If you set a breakpint on _sys_open, you should see it being hit 3 times, then should go on to reach main().If the Hello World app was compiled for source-level debug with -g then you will be able to debug main() at source level :)Hope this helpsStephen
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.
Sorry, I have no knowledge of the peripherals on the Intel platforms. You'll need to ask on the Intel forums.Peripherals are usually memory mapped, but each Execution Level (EL) can have a different view of memory.You can view these in the Memory view by prefixing the address with e.g. "EL3:" or "EL1N:"
https://developer.arm.com/documentation/101470/2024-0/Debugging-Embedded-Systems/About-address-spaces
For example, if the uart0 base address is, say 0xABCD0000, but it only exists in EL1N memory map, then you can view that by entering "EL1N:0xABCD0000" in the Memory view address field.Stephen
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.
Hi again,I'm glad to hear that you can access the peripherals programatically. The Debugger should be able to access the peripherals too.The Debugger's Memory view tries to read and display 1024 bytes by default from the base address you specify. If that memory range contains any "gaps" (addresses where there is no valid memory, and the memory read fails), then the Debugger will be unable to populate the Memory view. Are you seeing a page of pink? If so, try reducing the 1024 down to, say, 4.Alternatively, use the CLI in the Commands view. For example, if your peripheral is based at address 0xABCD0000, use:output /x *0xABCD0000To force a specific access size, add a cast:output /x *(char *)0xABCD0001 # byte size readYou can also use the "x" command - see:
https://developer.arm.com/documentation/101471/6-1-2/Arm-Debugger-commands/Arm-Debugger-commands-listed-in-alphabetical-order/x
Writing values to memory (default access size):memory set 0xABCD00000 0x99To force a specific access size (e.g. word sized write):memory set 0xABCD0000 32 0x99
https://developer.arm.com/documentation/101471/6-1-2/Arm-Debugger-commands/Arm-Debugger-commands-listed-in-alphabetical-order/memory-set
Hope this helps
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.
Hi BalerionGlad 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
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?
Balerion.
Hi again,
Sorry, I have no knowledge of the peripherals on the Intel platforms. You'll need to ask on the Intel forums.
Thanks for everything. This post can be marked as solved.