RISC-V debugging: data and instruction cache handling

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

    • RISC-V debugging: data and instruction cache handling

      Hello,

      I'm working on a debug unit for a custom RISC-V CPU and would like to get it working with the SEGGER J-Link debug probe and tools. Currently, the debug unit works fine with OpenOCD + GDB. Also with JLinkExe, I can successfully connect, downloading files, halt the CPU, and step through code. Setting breakpoints and more complicated operations don't work or are buggy and it appears that the reason might be the fact that the data cache is not flushed and that the instruction cache is not invalidated after memory writes. I know that there is no standardized way of doing this, e.g., OpenOCD uses a combination of fence and fence.i instructions.

      I'm just curious how the SEGGER debugger is handling caches in general and how I could add the flush/invalidation myself. This must be quite a common problem for other RISC-V CPUs as well, so maybe there is an elegant way to handle this.

      Thank you!

    • Hi Evan,

      For now, I did the following (which feels a bit hacked but seems to work):
      • After memory write access: Executing a fence.i and fence instruction. In my implementation, fence.i invalidates the instruction cache and fence flushes the data cache. This is mainly required to ensure that software breakpoints are visible to the CPU.
      • Before memory read access: Executing a fence instruction to ensure that the debugger reads fresh data from memory when looking at memory content. I added a check to see if the CPU is halted or not because it seems the hook is also called when doing background memory reads using the SBA.


      C Source Code

      1. int HandleAfterMemAccessWrite(U32 Addr, U32 NumBytes, U32 Flags)
      2. {
      4. int ret;
      6. JLINK_SYS_Report("Executing fence.i & fence instructions");
      8. JLINK_RISCV_DMI_AutodetectDMISettings();
      10. // Write fence.i instruction to progbuf0
      11. ret = JLINK_RISCV_DMI_WriteReg(0x20, 0x0000100f);
      13. // Write fence instruction to progbuf1
      14. ret = JLINK_RISCV_DMI_WriteReg(0x21, 0x0000000f);
      16. // Write to command register
      17. // regno: 0x1000
      18. // write: 0
      19. // transfer: 0
      20. // postexec: 1
      21. // aarpostincrement: 0
      22. // -> 0x00241000
      24. ret = JLINK_RISCV_DMI_WriteReg(0x17, 0x00241000);
      26. return 0;
      27. }
      29. int HandleBeforeMemAccessRead(U32 Addr, U32 NumBytes, U32 Flags)
      30. {
      32. int is_halted;
      33. int ret;
      35. is_halted = JLINK_TARGET_IsHalted();
      37. if (is_halted == 1)
      38. {
      39. JLINK_SYS_Report("Executing fence instruction");
      41. JLINK_RISCV_DMI_AutodetectDMISettings();
      43. // Write fence instruction to progbuf0
      44. ret = JLINK_RISCV_DMI_WriteReg(0x20, 0x0000000f);
      46. // Write ebreak instruction to progbuf1
      47. ret = JLINK_RISCV_DMI_WriteReg(0x21, 0x00100073);
      49. // Write to command register
      50. // regno: 0x1000
      51. // write: 0
      52. // transfer: 0
      53. // postexec: 1
      54. // aarpostincrement: 0
      55. // -> 0x00241000
      57. ret = JLINK_RISCV_DMI_WriteReg(0x17, 0x00241000);
      58. }
      60. return 0;
      61. }
      Display All