[SOLVED] savebin command and unmapped memory ranges

This site uses cookies. By continuing to browse this site, you are agreeing to our Cookie Policy.

  • [SOLVED] savebin command and unmapped memory ranges

    I have an ARM Coretex M0 I'm looking at with my JLink Pro, via SWD. When I look at memory via J-Mem, I see the memory values I'm expecting in the sections I know about, and I can see large swaths of the memory space that is not mapped. I'd like to dump to file what I see in J-Mem. JLink Commander's savebin command is not as helpful as I'd like because I have to know which sections of the memory address space are mapped. If I request all memory out to 0xffff_ffff, I of course get an error the first time savebin tries to read from an unmapped address. The thing is, I can't find a way to get a memory map through any JLink tools, so I'm left just endlessly scrolling through J-Mem trying to identify the boundaries of the mapped sections. There has to be a better way, especially because J-Mem has some reasonably performant way of recognizing which regions are mapped and which aren't.

    So how can I dump all of what I see in J-Mem with one simple command? Or how can I get a memory map so that I can dump memory with savebin without hitting regions that are unmapped?
  • Hi,

    There has to be a better way, especially because J-Mem has some reasonably performant way of recognizing which regions are mapped and which aren't.

    Sorry to say that but: No, it has not.
    J-Mem just uses a "optimized brute force" method of reading memory.
    First, J-Mem attempts to read the complete range currently displayed in the J-Mem window.
    If this fails, each displayed "line" is requested separately.
    If a read of a line fails, J-Mem requests each byte* of this line separately. (*under certain conditions, half word/word/double word)

    Furthermore, the J-Link software does not know anything about the memory map of a target device if only a core(e.g. Cortex-M0) is specified.
    If a device is specified (e.g. Atmel SAMD21G18), the J-Link software knows the location of the supported flash memories and the address of the RAM that should be used as Work-RAM.
    (And for some devices, all additional RAM locations that should be searched for a RTT Block when the J-Link software checks if RTT is running on the target)
    However, J-Mem does not use this information in any case, it proceeds as described above.

    Please note that some devices will return data even if if no memory is available for an accessed address, e.g. some ST devices return 0x00.
    Please also note that some devices will stall/halt/reset/abort/fault or behave unpredictable when a read from a memory address not specified/used/implemented by the device manufacturer is issued via the debug interface (or sth. regardless who issued the access ).

    Therefore, (from my point of view) using J-Mem in this way is not a reliable way to receive information about available memory of a device.

    Currently, there is not feature / function in the J-Link software which prints a memory map of a device.
    If such a feature existed, it wouldn't be very useful, as all information the J-Link software could provide is available in the public reference manuals of the respective devices, and furthermore the information provided would not necessarily be complete, as the J-Link software only knows about memory it supports and/or can use.

    Best regards,
    Would you like to be added to the J-Link software update notification list, so you get informed automatically when a new version becomes available?
    Just write me a PM or in case you want to subscribe to it yourself, please use this link: Link
    Notification for J-Link, J-Link Debugger, SystemView & J-Scope: Link
    Notification for Embedded Studio: Link