Skip to content

Fix for debugging when trying to load to ram. #87423

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 1 commit into
base: main
Choose a base branch
from

Conversation

EmilioCBen
Copy link
Collaborator

Fixes #87422
When users try to debug while flashing into ram,
JLink/Linkserver would fail to flash straight to ram. Each with their own issues. Both would reset after load which would flush the ram and point the PC to flash. Linkserver treated the ram as inaccessible, and the added memory region in board.cmake has the incorrect size for the region and is already included inside linkserver.

decsny
decsny previously requested changes Mar 20, 2025
@@ -6,10 +6,7 @@

if(CONFIG_SOC_MIMXRT1176_CM7 OR CONFIG_SECOND_CORE_MCUX)
board_runner_args(pyocd "--target=mimxrt1170_cm7")
board_runner_args(jlink "--device=MIMXRT1176xxxA_M7" "--reset-after-load")
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

don't we want to reset after load for the more expected use case of actually booting with the ROM? or is this just what is now the default?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This should be the default, this seems to be the default for the other boards as well which is one step that prevented them from running into this issue.

Comment on lines +153 to +156
# If the flash node points to ram, linserver treats
# the ram as inaccessible and does not flash.
gdb_cmd += ['-ex', 'set mem inaccessible-by-default off']
gdb_cmd += ['-ex', 'monitor reset', '-ex', 'load']
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

isn't this a problem with linkserver and not this zephyr runner?

@@ -421,7 +421,7 @@ def do_run_common_image(command, user_args, user_runner_args, used_cmds,
# the board has enabled this functionality, check if the board should be
# reset or not. If this is not specified in the board/soc file, leave it up to
# the runner's default configuration to decide if a reset should occur.
if runner_cls.capabilities().reset and '--no-reset' not in final_argv:
if runner_cls.capabilities().reset and '--no-reset' not in final_argv and len(board_image_count):
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

the comment should be updated about what is this doing, I don't understand

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is not something that should be addressed in this PR. The intention of the comment makes sense, the implementation uses a default set of conditions for multiple images if none are passed in as parameters, the only update I made is it doesn't properly check or test rather this code runs if there's only one image so I added the check. I have nothing to do with the implementation so maybe my assumption of the comment is wrong as well thus I cannot make the change.

Comment on lines -10 to -12
# ITCM is not defined in RT1170's LinkServer device file
board_runner_args(linkserver "--override=/device/memory/-=\{\"location\":\"0x00000000\",\
\"size\":\"0x00040000\",\"type\":\"RAM\"\}")
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

the comment here makes me think once again that the device memory map linkserver issue is not a zephyr problem

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This code is actually wrong, and Linkserver has the correct mapping for this address space. Specifically, we gave the wrong size when this line was created but again no longer needed since Linkserver has the correct address mapping.

@EmilioCBen EmilioCBen changed the title Fix for debugging when trying to flash to ram. Fix for debugging when trying to load to ram. Mar 20, 2025
@@ -421,7 +421,7 @@ def do_run_common_image(command, user_args, user_runner_args, used_cmds,
# the board has enabled this functionality, check if the board should be
# reset or not. If this is not specified in the board/soc file, leave it up to
# the runner's default configuration to decide if a reset should occur.
if runner_cls.capabilities().reset and '--no-reset' not in final_argv:
if runner_cls.capabilities().reset and '--no-reset' not in final_argv and len(board_image_count):
if board_image_count is not None:
reset = True
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@nordicjm your PR #69748 made the initial change here with respect to board_image_count and the forced addition of reset. What we found is that the test here for not None is always true because board_image_count is instantiated but doesn't have any elements in it... so not None. This results in the runner always adding a reset to the gdb commands. I suspect, from your comment block above, that this wasn't your intention.

We didn't notice this change because in the normal debug situation, you wouldn't care if the gdb did reset, load, reset if the image was being put in flash. But if you are targeting an image to a RAM space, the reset, load, reset causes the bootrom to load the flash image preventing you from debugging the image you created for RAM loading/debugging.

In parallel to this PR being added, I just saw this other PR [#87138] (@VynDragon) that just merged to force the larger logic to NOT ignore the no-reset runner option. We could have done the same thing now that I see this but I'm still questioning the logic of "if board_image_count not None" when combined with the comment block about multiple images.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

board_image_count is init in the common function, it should not not ever be none. As for why I put the none check in, I do not remember

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

so in this particular case, the len(board_image_count) was 0 and we needed to have this check to keep the rest of your logic from doing another reset.

@decsny decsny dismissed their stale review March 31, 2025 22:02

removing block because lost track of this PR

@EmilioCBen EmilioCBen force-pushed the fix/mimxrt1170_flash_ram branch from cd5a1a8 to edae439 Compare April 1, 2025 14:18
When users try to debug while flashing into ram,
JLink/Linkserver would fail to flash straight to ram.
Each with their own issues. Both would reset after
load which would flush the ram and point the PC to flash.
Linkserver treated the ram as inaccessible, and the added
memory region in board.cmake has the incorrect size for the
region and is already included inside linkserver.

Signed-off-by: Emilio Benavente <[email protected]>
@EmilioCBen EmilioCBen force-pushed the fix/mimxrt1170_flash_ram branch from edae439 to add46b5 Compare April 25, 2025 16:21
@pdgendt pdgendt assigned dleach02 and unassigned pdgendt Apr 29, 2025
@pdgendt
Copy link
Collaborator

pdgendt commented Apr 29, 2025

Re-assigned as I can't comment on the changes.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

RT1170 fails to load program when debugging from ram.
6 participants