I've got a PIC32/MIPS project that heavily uses the TLB to map memory dynamically (virtual memory manager). It seems that if J-Link goes out and requests an address that isn't in the hardware TLB table, an exception is thrown. Is there a way to get jtag to respect the TLB?

Here's the scenario: I have a TLB interrupt handler that loads the TLB table. If I am accessing addresses in running code that aren't in the map in software, they would get loaded by the interrupt/exception. However if I'm at a breakpoint and a debug window (trace/memory) either intentionally or accidentally access unmapped memory (usually what happens) the happily progressing debug session vectors into an exception indicating a bad memory address access from the EJTAG segment DMSEG (0xFF200000).

It would be super great if somehow there were a way to make such bad memory accesses either:
1) Just read all 0's and not throw an exception or...
2) (BEST:) actually try to run my tlb exception handler which would load the hardware TLB.
3) Some way to force my debugger (eclipse/sourcery code control gdb) to never try to walk the stack. 99% of the time stack trace is what walks into unmapped memory.

If #2 could be done it would be awesome. The debugger would work happily with virtual memory managers. if not, my debugging sessions are very painful. I have to watch out that I don't view variables or memory that wasn't just accessed in code.

Anyone have experience with this issue? It seems like a basic requirement for Jtag with MIPS/pic32-- a feature that should be there. Maybe I'm overlooking something.

Thanks!!

I guess nobody is using TLB (A basic feature of MIPS!!). Segger- You should keep ahead of Microchip on this one and add support. I think many of us have switched over to you guys due to the poor tools from them, but if they support it I will be forced to go back. Save us!

I think all you would have to do at a minimum is prevent the MIPS core from getting vectored to an interrupt in the target app when the Jtag reads a memory address that isn't mapped/valid. This would make debugging with TLB at least possible at some level. Bonus points if you allow the TLB exception to run when JTAG reads an unmapped address. This would cause it to map properly and become valid.

Pretty please!! Thanks

Hi Alex,

Thanks! Just reading zeros would allow me to actually debug

On #2, it may be possible with minimal effort to trigger the TLB exception vector to also run when the DMSEG does an illegal address just as it normally does in user code. Microchip (when I spoke with them) seemed to think this was the case and was going to add it. (It took eons to get to someone that knew what I was talking about-- so KUDOS to you guys .. I get an expert in days!! )

I would disagree on your argument for not doing #2. Obviously you can't support everything on every processor-- so I would say maybe the issue might be more of dev time (and how many users would actually benefit). I assert that this is a basic feature of MIPS-- and while most don't use it yet they will. SoC operating systems are going to need this.

The TLB exception is usually a dozen lines that reads an array and loads entries in the hardware. With this, you get a working virtual memory system while you debug. Without it-- well, you can't debug a SoC operating system of any decent complexity.

Thanks for getting back!!


-Tj

It's been a painful many months of carefully avoiding the act of causing the debugger to try and load memory mapped via the TLB unless the code has recently touched said memory. To do so causes a spurious vector of the CPU into the general exception with the address 0xFF200000 (JTAG debug addr). I've finally gotten to the point of not being able to even limp along. I'm hoping there is a work around that has been added in one of the J-Link software versions since my first email on the subject.

With this issue, one must be very careful at exaclty what they watch and when, and remove any watches when finished. It's debugging on eggshells!

The problem I can't seem to work around is that eclipse/gdb will request "-thread-info 1" which responds with the current frame. This would be fine if it did not try to look through the pointers on the stack into TLB memory. Here's the GDB trace at the very moment I get this issue (with red underline at the exception/error} )


638,463 93^done,threads=[{id="1",target-id="Thread ",frame={level="0",addr="0x9d045f88",func="\
SCRIPTDBG_OpenDebugSession",args=[{name="pCS",value="0x80071614"},{name="pFileName",value="0xc012f69\
0 \"/UTILS/EDIT.EXE\""},{name="CD",value="0xc012ff50 \"\\004\\001\\005\\001\\006\\001\\a\\001\\b\\00\
1\t\\001\\n\\001\\v\\001\\f\\001\\r\\001\\016\\001\\017\\001\\020\\001\\021\\001\\022\\001\\023\\001\
\\024\\001\\026\\001\\030\\001\\003\""},{name="CD_END",value="0xc012fff8 \"\\220\365\\022\300\315\31\
5\315\315\"<error: Cannot access memory at address 0xc0130000>"},{name="PC",value="0xc012f768 \"S\35\
4\\001Uq\""},{name="LAST_BYTECODE",value="0xc012fedd \"\\003\\060\\024&\""}],file="S:/Projects/Compu\
te/Source/Firmware/src/Scripting/scriptdebug.c",fullname="s:\\projects\\compute\\source\\firmware\\s\
rc\\scripting\\scriptdebug.c",line="2869"},state="stopped"}]

The setup of J-Link/Eclipse/Pic-32 would probably be working very well if it were not for this issue. It causes a good amount of pain tiptoeing around the debugger, being careful not to watch or hoover over a variable that wasn't just accessed.

I'm hopeful there is a workaround. Does anyone know if it is possible to cause GDB to simply not try and look at the addresses pointed to by function parameters? Alex, is this something that has been addressed? Any tricks? I seem to have hit a point in my project that (due to this issue) has caused me to simply be unable to debug certain functions at random. Way back last October we discussed having the debugger return 0's for unmapped addresses. This would also fix the issue.

Thanks for any hints/help!

-Tj

I'm increasingly confused. I am using a basic feature of MIPS and microchip's tools fail to support or handle debugging with TLB as do 3rd party tools like J-Link. I can't really fault Segger on this because the market for things like J-Link exists because OEM solutions are increasingly terrible. Maybe I'm an old timer-- but in the 90's I remember buying things like TI DSP dev-kits and having things like support/manuals/and basic functionality working. Today we have the equivalent of swiss army knives that fall apart when opened. essentially with support manned by people that know little other than the basics (Note: I am not referring to Segger!) . Do anything beyond hello world and they get stumped. There used to be a better time.

Anyway-- does anyone code on the PIC32 and make use of TLB in here and successfully use J-link to debug? I can't -- no, I *REFUSE* to believe that I am the only one using a major chip peripheral and in a year nobody has chimed in here Or maybe I am the only one. My hope is that I'm not and I'm doing something dumb. I'm very interested if anyone out there is using TLB/Pic32/jlink.

Forget TLB. Debugging with the Segger J-Link will cause the CPU to vector into a general exception if you try to view any bad pointers.

This can happen if you hover the mouse over a variable that isn't initialized, or if some members of a struct (pointers) are uninitialized and you happen to use the watch window on the parent struct.

In other words: It happens ALL THE TIME through the general course of debugging any program.

It's been over a year since I initially posted in this forum, and I still spend many late nights fighting this issue.

I stand baffled that Segger has not responded other than to acknowledge the issue and mention that it would be fixed possibly in the next release (again, over a year ago). No response from any users on this either. So I assume nobody is using Pic32 with J-Link, at least not to any meaningful degree.