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