Using debugger for code run in RAM (SDRAM)

[ch1648]

Currently debugger issues Reset command after loading code to device.
This does not work to debug application loaded and run in RAM (SDRAM).
Because the Jlink Reset command will reinit the SDRAM and erase code loaded to RAM (SDRAM)

Is it possible to add a configuration in launch.json to specify an application run in RAM and thus will issue Reset/Halt command first and then load the code.

I added the following postLaunchCommands and it seems work around the issue for now, but this will need to download the code twice.

        "postLaunchCommands": [
            "monitor clrbp",
            "monitor reset",
            "monitor halt",
            "monitor regs",
            "file /mnt/c/sandbox/myapp.elf",
            "load",
            "monitor halt",
            "tb main",
       ],

[beg0]

Hi ch1648,

I had the same issue. I resolved the issue by forcing launch commands in launch.json

If using openocd and a ST-Link debug probe, I add the following:

{
           // ....
           // other config in your launch.json
          
            "overrideLaunchCommands": [
                "-interpreter-exec console \"monitor reset halt\"",
                "-target-download",
               // "-interpreter-exec console \"monitor reset halt\"",
                "-enable-pretty-printing",
            ],
}

If you are using a JLink probe, you probably should use:

{
           // ....
           // other config in your launch.json


            "overrideLaunchCommands": [
                "-interpreter-exec console \"monitor halt\"",
                "-interpreter-exec console \"monitor reset\"",
                "-target-download",
               // "-interpreter-exec console \"monitor reset\"",
                "-enable-pretty-printing",
            ],
}

Note that commands are not "magic", it's the content of the launchCommand() from https://github.com/Marus/cortex-debug/blob/master/src/jlink.ts#L40, but we commented the second "reset" command (the one which actually is reseting the SRAM).

By the way, thank you @Marus and al. to make the Cortex-debug extension and to allow it to be so versatile and so powerful. That allows to overcome issues in most unusual situations.

[haneefdm]

With various devices and gdb-servers the definition of reset is complicated. With OpenOCD, it defines a convention -- see here. As you can see (in links below) there are so many variations of a reset, the device vendor provides scripts on how a reset happens and this is not uniform. Doing a reset may or may-not reset peripherals. We don't know. Dual/multi processors are even more fun :-)

http://openocd.org/doc/html/General-Commands.html#resetcommand
https://www.segger.com/downloads/jlink/UM08001

What we try to do is to do a 'reset & halt' (together if possible) before programming. In case the MCU is stuck in an exception handler, it will be freed.

Next is programming, which may use the MCU itself to do the programming (usually in chunks) and potentially leave the SP, PC in a random state.

So, we need a second reset to put things back into a known state (hopefully) and run YOUR program

This recipe generally works for most people but when it doesn't then override.... commands to the rescue. I was (partially) the reason why we introduced those commands.

[ch1648]

Hi beg0, Thank you. the jlink script I have will reinitialize the SDRAM when reset command is issued thus clear all the content downloaded before. I worked around the issue by load the image again after reset command in postLaunchCommands.  But it will need to load the same images twice which slow down the start of debugger. On Tuesday, June 22, 2021, 06:06:36 AM PDT, beg0 ***@***.***> wrote: Hi ch1648, I had the same issue. I resolved the issue by forcing launch commands in launch.json If using openocd and a ST-Link debug probe, I add the following: { // .... // other config in your launch.json "overrideLaunchCommands": [ "-interpreter-exec console \"monitor reset halt\"", "-target-download", // "-interpreter-exec console \"monitor reset halt\"", "-enable-pretty-printing", ], } If you are using a JLink probe, you probably should use: { // .... // other config in your launch.json "overrideLaunchCommands": [ "-interpreter-exec console \"monitor halt\"", "-interpreter-exec console \"monitor reset\"", "-target-download", // "-interpreter-exec console \"monitor reset\"", "-enable-pretty-printing", ], } Note that commands are not "magic", it's the content of the launchCommand() from https://github.com/Marus/cortex-debug/blob/master/src/jlink.ts#L40, but we commented the second "reset" command (the one which actually is reseting the SRAM). By the way, thank you @Marus and al. to make the Cortex-debug extension and to allow it to be so versatile and so powerful. That allows to overcome issues in most unusual situations. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or unsubscribe.