adamgreen / mri

MRI - Monitor for Remote Inspection. The gdb compatible debug monitor for Cortex-M devices.
Apache License 2.0
155 stars 57 forks source link

Invalidate instruction cache after memory writes #33

Closed icecream95 closed 2 years ago

icecream95 commented 2 years ago

GDB uses the 'X' command to set software breakpoints, so invalidate the instruction cache to make sure that the patched-in breakpoint instruction is executed when execution continues.


In the Makefile, it appears that armv7-m.c is only compiled for the different FPU variants, not based on whether there is a separate instruction cache or not. So if it is compiled against a cmsis.h which doesn't define an instruction cache, breakpoints will not work on a device that does.

So maybe the Platform_InvalidateICache function should be defined in board-specific code?

However, the Makefile is already broken, with compilation failing like this, at least when using the toolchain from the gcc-arm-none-eabi Debian package:

Compiling architectures/armv7-m/armv7-m.c for FPU_HARD
In file included from architectures/armv7-m/armv7-m.c:22:
architectures/armv7-m/debug_cm3.h:19:10: fatal error: cmsis.h: No such file or directory
   19 | #include <cmsis.h>
      |          ^~~~~~~~~
compilation terminated.
make: *** [Makefile:299: obj/armv7-m/fpu_hard/architectures/armv7-m/armv7-m.o] Error 1

I am using my own Meson project rather than make, which uses my own set of CMSIS headers, so for me this isn't a problem.

adamgreen commented 2 years ago

@icecream95 Thanks for this PR. Sorry for taking so long to get back to you on this issue but I was busy with another project that I wanted to get to a good point before I switched gears to look at MRI for a bit.

When I first started working on MRI, I knew that caches could introduce issues like this but I just decided to put my head in the sand until I actually had a test case to test anything I tried since all of the microcontrollers I was working with at the time had no real caches. The ARMv7-M Architecture Reference Manual that was available at the time I started working on MRI didn't even document the cache maintenance related registers so I also have that in my defense :)

I will try getting MRI to run on my Portenta again since it has caches. This will let me test your PR and merge it.

Are you still actively using MRI on the device where you hit this issue? The reason I ask is that I might make a few other changes in MRI related to the cache and I was wondering if you would be able to test them as well?

adamgreen commented 2 years ago

@icecream95 Thanks again for the PR. It has been merged.

I did make a few updates that should allow it to run on any microcontroller from the ARMv7-M family, even those without caches.

I have tested it on an Arduino Portenta-H7 (Cortex-M7) which has caches and a LPC1768 (Cortex-M3) which doesn't. It appears to do the right thing on both. It would be great if you could test it on your hardware as well.