Problem with flashing action/armdbg in VSCode extension

In updating my development environment to the new VS Code extension/environment(coming from uVision), I'm experiencing some issues with the flashing utility. 

It seems that erasing the chip (in this case a HyperFlash chip connected to an MIMXRT1052CVL5B), is no problem, but when the tool tries to write the firmware to flash, it's unable to do so. 
I verified the sectors are actually erased, so that all seems to be executed well.

And with uVision I'm not experiencing the same problem with seemingly the same settings.

uVision configuration:

VS Code configuration:

As far as I can see, both should perform the same flashing operations, however the VS Code debugger only erases the chip, and fails programming with the following output:

"

* Executing task: Flash Device

Stopping running target Cortex-M7 on connection
Connected to running target Cortex-M7

Execution stopped in Privileged Thread mode at 0x604024D2

0x604024D2 BHI {pc}-6 ; 0x604024cc

Mapping segment 0x60400000 ~ 0x606B90D8 (size 0x2B90D8)

Starting flash programming operation: Programming 2855128 bytes to 0x60400000

Flash Progress: 0% (Erasing)

Flash Progress: 40% (Erased 2883584 bytes)

Flash Progress: 40% (Erasing completed)

Flash Progress: 40% (Writing)

Flash Progress: 85% (Writing failed)

Flash Progress: 85% (Programming failed)

Disconnected from stopped target Cortex-M7

ERROR(?): Flash programming failed: Failed to program 200 bytes at 0x60402400: 1

Flash failed

* The terminal process terminated with exit code: 1.

"

*Note: Application data starts at 0x60400000, due to the bootloader using which resides on the same chip.

I've also tried to make a custom armdbg command, but I can't seem to get the correct combination of arguments, which reflect the uVision configuration: 

"

.\armdbg --program-only --target="<TARGET>" --log-config=info --clock-speed=25MHz --connect-pre-reset=true --workspace-folder="<WORKSPACE>" --image="<AXF_IMAGE>" --probe="ULINKpro" --stop-on-connect=true --port-mode="SWD" --cmsis-pdsc="D:\CMSIS\NXP\MIMXRT1052_DFP\19.0.0\NXP.MIMXRT1052_DFP.pdsc" --cmsis-device-name="MIMXRT1052CVL5B" --flash-config="algorithm=D:\CMSIS\NXP\MIMXRT1052_DFP\19.0.0\devices\MIMXRT1052\arm\MIMXRT105x_HYPER_256KB_SEC.FLM,region_start=0x60000000,region_size=0x04000000,ram_start=0x20000000,ram_size=0x00008000,erase_method=SECTORS,verify=true"

"

If anyone could help me with this, it would be greatly appreciated. 

Parents
  • After a process of elimination, I've found that the RAM that needs to be allocated for the flashing algorithm subtely changed between flashing programs. 

    When I set the RAM_size variable to 0x00020000, the flashing algorithm runs correctly. (size was arbitrarilly based on the full size of the OCRAM in the MCU)

    It seems that the armdbg process requires an ever so slightly bigger RAM pool to do it's work, when comparing to the "old" uVision process.

Reply
  • After a process of elimination, I've found that the RAM that needs to be allocated for the flashing algorithm subtely changed between flashing programs. 

    When I set the RAM_size variable to 0x00020000, the flashing algorithm runs correctly. (size was arbitrarilly based on the full size of the OCRAM in the MCU)

    It seems that the armdbg process requires an ever so slightly bigger RAM pool to do it's work, when comparing to the "old" uVision process.

Children
No data