Import FPV model : Failed to read 4 bytes from address 0

Hello, I have moved your query to the Arm Development Studio dedicated forum.

I don't know which FVP you are using, is memory implemented at this address?

I see it is address 0x0. Perhaps this is ITCM memory that is not yet enabled?

If you connect without any code loaded, can you access this address?

Can you access it at higher exception levels (EL3:0x0).

If the FVP you are using is public, can you advise which you are using?

Ronan, thanks for the replay,

Memory should be defined at address 0.  The output of "info memory" is listed below:

Num Enb Low Addr High Addr Attributes Description
1: y NP:0x0000000000000000 NP:0xFFFFFFFFFFFFFFFF rw, nocache, verify Memory accessed using normal world physical addresses
2: y N:0x00000000 N:0xFFFFFFFF rw, nocache, verify Memory accessed using normal world addresses
3: y EL1N:0x0000000000000000 EL1N:0xFFFFFFFFFFFFFFFF rw, nocache, verify Memory accessed using EL1 normal world addresses

I also attempted to load code manually using the command "load my.axf" which produced the error message below.
ERROR(CMD16-TAD59-NAL82):
! Failed to load "my.axf"
! Download of 131,512 bytes to address EL1N:0x0000000000000000 failed while writing block of 1,024 bytes to address EL1N:0x0000000000000000
! Error attempting to perform memory operations

I revied information about the error code "CMD16-TAD59-NAL82" from here community.arm.com/.../error-cmd16-tad59-nal33 however I don't see a reason why that would be applicable in this case

Here are a few other details for register settings related to memory:

SCTLR.M = 0 (Translation disabled)
ID_AA64MMFR0_EL1.PARange = 48 bits

For the time being EL3 and EL2 are disabled
ID_AA64PFR0_EL1.EL3 = 0
ID_AA64PFR0_EL1.EL2 = 0
ID_AA64PFR0_EL1.EL1 = 1
ID_AA64PFR0_EL1.EL0 = 1

Thanks for any advice.

All the debugger knows is that it tried to write to the address on the target, and it failed to verify that it completed (as it is a read error).

As a simple test - can you attempt to access the address directly on the command line, with something like:

memory set EL1N:0x0 32 0xDEADBEEF

Does this complete successfully?

I'm not sure what the effect of those bits would be - they are read-only on the standard FVP and so I cannot modify.

I see the same error irrespective of address used:

memory set EL1N:0x0 32 0xDEADBEEF
ERROR(TAD11-NAL82):
! Failed to write 4 bytes to address EL1N:0x0000000000000000
! Error attempting to perform memory operations

memory set EL1N:0x8000000 32 0xDEADBEEF
ERROR(TAD11-NAL82):
! Failed to write 4 bytes to address EL1N:0x0000000008000000
! Error attempting to perform memory operations

dump memory /tmp/foo 0x0 0x7
ERROR(TAD10-NAL82):
! Failed to read 8 bytes from address EL1N:0x0000000000000000
! Error attempting to perform memory operations

dump memory /tmp/foo 0x80000000 0x80000000
ERROR(TAD10-NAL82):
! Failed to read 1 bytes from address EL1N:0x0000000080000000
! Error attempting to perform memory operations

Try loading the image directly on the FVP (ie do not use Debugger at all) via the command line:

fvp_executable -a image.axf

All signs point to an issue with the FVP, not the debugger...

Running from the command line the model and code work as expected.

Do any of these command complete successfully?

The 32 or 8 reflects the width of the bus access.

NP/SP refer to (non)secure physical addresses.

memory set NP:0x0 32 0xDEADBEEF
memory set SP:0x0 32 0xDEADBEEF

memory set NP:0x0  8 0xDEADBEEF
memory set SP:0x0  8 0xDEADBEEF

Also, do you use Iris or CADI to connect to your FVP?

Hi

My name is Stephen and I work at Arm.

To follow-up on my colleague Ronan's suggestions, if the Debugger is connected to your model via Iris, then you can get diagnostic logging information by adding the "--iris-log" (or -i") option to the Model Parameters field in the connection dialog.

FVP_Base_Cortex-A720 --help
shows
-i, --iris-log                 Iris log level (may be specified multiple times), example: -ii for level 2

When I try this with FVP_Base_Cortex-A720, I see a lot of initial connection logging in the Target Console.
Once that settled down:

memory set EL1N:0x0 32 0xDEADBEEF

reported:

IrisGI:REQ:2599: rddi_debug -> component.FVP_Base_Cortex_A720.cluster0.cpu0 memory_write(instId:44 /*0x2cu*/, spaceId:2, address:0, data:[0xdeadbeef], byteWidth:4, count:1)
IrisGI:RES:2599: rddi_debug <- result={}
IrisGI:REQ:2600: rddi_debug -> component.FVP_Base_Cortex_A720.cluster0.cpu0 memory_read(instId:44 /*0x2cu*/, spaceId:2, address:0, byteWidth:4, count:1)
IrisGI:RES:2600: rddi_debug <- result={data:[0xdeadbeef]}

followed by the Debugger reading more data to update the (larger) Disassembly view:

IrisGI:REQ:2605: rddi_debug -> component.FVP_Base_Cortex_A720.cluster0.cpu0 memory_read(instId:44 /*0x2cu*/, spaceId:0, address:0, byteWidth:4, count:128 /*0x80u*/)
IrisGI:RES:2605: rddi_debug <- result={data:[0xe800e800deadbeef, 0xe800e800e7ff0010, 0xe800e800e7ff0010, 0xe800e800e7ff0010, 0xe800e800e7ff0010, 0xe800e800e7ff0010, 0xe800e800e7ff0010, 0xe800e800e7ff0010, 0xe800e800e7ff0010,
:
0xe800e800e7ff0010, 0xe800e800e7ff0010, 0xe800e800e7ff0010, 0xe800e800e7ff0010, 0xe800e800e7ff0010, 0xe800e800e7ff0010, 0xe800e800e7ff0010]}

Please could you try the same?


Furthermore, the Arm-supplied FVP_Base_Cortex-A* family models all have secure memory.  For all the Examples provide in Arm DS, this is disabled with:

-C bp.secure_memory=false

Maybe you could try that too?

Stephen

I ran with --iris-log ( the bp.secure_memory parameter is not available I assume that is expected as EL3 is disabled)  after loading I see slow but continuous stream of messages like the ones below. I did not see any additional log messages after the "memory set" command

IrisGI:RES:1599: rddi_debug <- result={data:[0x1]}
IrisGI:REQ:1600: rddi_debug -> component.project.cpu.cpu0 resource_read(instId:10 /*0xau*/, rscIds:[0x2a9])
IrisGI:RES:1600: rddi_debug <- result={data:[0x1]}
IrisGI:REQ:1601: rddi_debug -> component.project.cpu.cpu0 resource_read(instId:10 /*0xau*/, rscIds:[0x2a9])
IrisGI:RES:1601: rddi_debug <- result={data:[0x1]}
IrisGI:REQ:1602: rddi_debug -> component.project.cpu.cpu0 resource_read(instId:10 /*0xau*/, rscIds:[0x2a9])
IrisGI:RES:1602: rddi_debug <- result={data:[0x1]}
IrisGI:REQ:1603: rddi_debug -> component.project.cpu.cpu0 resource_read(instId:10 /*0xau*/, rscIds:[0x2a9])

Hi again Brad,

Sorry your message got filtered by the moderation software, it can be very sensitive. Don't worry, no harm done.

You can use <FVP> --list-params > params.txt to see all the available parameters, bp.secure.memory may be something slightly different on your FVP.

Looking at the log, I see a lot of REQuests and RESponses, which are likely the debugger detecting the individual blocks inside the FVP.

IrisGI:REQ:1600: rddi_debug -> component.project.cpu.cpu0 resource_read(instId:10 /*0xau*/, rscIds:[0x2a9])
IrisGI:RES:1600: rddi_debug <- result={data:[0x1]}

It is worrying that there is no log after trying to perform the write... this says to me that the debugger never manages to pass that request to the model (this log is from the FVPs point of view).

This may be a difficult one to solve in a public forum... you may need to raise an official (private) support case from the Support section below. You can reference this thread so that the team have some history.

Thanks for looking. I opened a support request.

Just in case this helps here or with the support ticket I found the following in the debugger error log

!ENTRY com.arm.debugger.ux 4 0 2025-06-23 14:02:37.574
!MESSAGE Unable to map memory space NON_SECURE
!STACK 0
com.arm.debug.interpreter.ds.DSException: Failed to load "my.axf"
at com.arm.debug.interpreter.ds.commands.file.AbstractFileCommand.executeOrUnload(AbstractFileCommand.java:84)
at com.arm.debug.interpreter.ds.commands.file.LoadCommand.execute(LoadCommand.java:48)
at com.arm.debug.interpreter.ds.commands.file.LoadCommand.execute(LoadCommand.java:1)
at com.arm.debug.interpreter.ds.DSInterpreter$3.run(DSInterpreter.java:369)
at com.arm.debug.interpreter.ds.DSInterpreter$3.run(DSInterpreter.java:1)
at com.arm.debug.core.engine.connection.ConnectionEventManager$QueuedTask.run(ConnectionEventManager.java:94)
at com.arm.debug.core.engine.connection.ConnectionEventManager.processTask(ConnectionEventManager.java:305)
at com.arm.debug.core.engine.connection.ConnectionEventManager.access$8(ConnectionEventManager.java:303)
at com.arm.debug.core.engine.connection.ConnectionEventManager$2.run(ConnectionEventManager.java:208)
at com.arm.debug.control.CommandTask.fillInStackTrace(CommandTask.java:78)
at com.arm.debug.control.ConnectionController.execute(ConnectionController.java:1959)
at com.arm.debug.api.AbstractCommands.execute(AbstractCommands.java:115)
at com.arm.debug.api.Commands.consoleCommand(Commands.java:149)
at com.arm.debug.views.debugConsole.DebugConsolePage.commandIssued(DebugConsolePage.java:779)
at com.arm.debug.views.debugConsole.DebugCommandLine.notifyListeners(DebugCommandLine.java:160)
at com.arm.debug.views.debugConsole.DebugCommandLine.keyTraversed(DebugCommandLine.java:246)

.....