Hello Folks，
As mentioned in the title, my environment and hardware are normal, because when the size of the downloaded fip.bin file is small (for example, within 100KB), the download is successful, but when the fip.bin file is large (for example, 146KB), the following error message will be reported. mistake. Disconnect ads and try again and still get an error.
Is this a bug in the ads software? I used jlink to download the same bin, and the download, verification, and operation were all normal. Once again, it proved to be a bug in ads or a misconfiguration somewhere?Thanks
The download command is as follows： restore X:\build\fip.bin binary 0x00080000
download 146KB bin file：ads 2023.0 report error
download 101KB bin file：everything is normal
Software version：
HiMy name is Stephen and I work at Arm.I'm not aware of any issues with Arm DS Debugger in this area. I can successfully "restore" much larger images.The error message reports that the "target is running". For the "restore" command to work, the target must not be running.Try splitting your script into smaller sections, and check that the target is stopped before executing that command.Or did the target start running whilst the command was executing?Hope this helpsStephen
Hi Stephen，
1. The target is not running2. Can you test ads2023.0 retrore in a large bin to see if it works properly?3. How to explain that using jlink to download is normal?4. How should we explain the following two phenomena?
Hello,
I cannot replicate this - can you share which device you are using?
Is the issue related to how this memory is accessed? You could use the `memory` command to define the access mode (eg 8-bit accesses).I don't know, but perhaps that is what J-link uses?
developer.arm.com/.../memory
Hi againTo which type of processor is the "restore" command operating? Is it the A55 or a Cortex-M-class processor?In the script, please try adding an "AHB:" prefix to the address being restored, e.g.:restore X:\build\fip.bin binary AHB:0x00080000This will result in the memory being accessed directly by DSTREAM, rather than accessing memory via the processor.You might need to tweak the AHB parameter (e.g. "AHB_0:" instead of "AHB:") depending on the buses that are present.Use the "info memory" command to tell you which memory spaces are available and which AHB parameter to use.Stephen
Hi againTo follow-up on this issue, some good news!We've identified a problem with Arm DS 2023.0 and earlier when "restore"-ing images larger than 128K to M-class devices. A workaround is to use an address-space prefix such as AHB:0x...This issue is now fixed in Arm DS 2023.1.Stephen