OK, there is something off here, but I cannot really tell what it is. What you indicate is not necessarily misuse of the trace buffer. The trace buffer logs the last 16 discontinuities seen by the program sequencer, which includes function calls, interrupts, exceptions, returns from each of these events, and jumps (and optionally loops)...if this is early enough in the CRT code, then there may have been no function calls or jumps, so the only thing that would cause a discontinuity would by an asynchronous event. If you have breakpoints before whatever is causing this problem, then the trace could be blank. And if the first discontinuity is this pairing that shows when you run with NO breakpoint, then that is the problem...but it is difficult to figure. According to this, the source of this discontinuity is the RTI instruction at 0xFFA00092. If this were a conventional interrupt service routine (ISR), then the RTI would be the end of the ISR, and that would mean an interrupt would have occurred previously, which would have been caught by the trace buffer because an interrupt is a disruption to program flow. That said, the only RTI in the CRT code that I am familiar with is the one used to go to Supervisor mode, which is not a conventional ISR and therefore wouldn't have an entry point discontinuity. That part makes sense. What does NOT make sense is the destination of the discontinuity, which you show as an instruction r0 = 9;, which is located in SDRAM somewhere pretty high up. If it were the RTI I know of, the destination would be the same instruction address in internal memory...so I am confused as to what you are showing here.
It could be a problem with the device itself, but it would be better to see details around the failure before making that conclusion...what you've indicated so far does not appear to be a failure. Your original post said that you were halting at the _fatal_exception loop, which is what I was trying to help you explore. But the last two posts are indicating that you are halting in the CRT somewhere, and there is no error being reported. Are you now unable to get to the fatal_exception halt point that you originally asked about?