I'm having a problem with MPC8347 freezing and getting completely locked while debugging.
I'm using CW and USB Tap but get the same lock-ups with BDI2000, lock-up happens at some very simple assembly instruction like "lwz r1,NNN(r2)". If I set a breakpoint somewhere else or let code run freely - everything works.
Here is what I've checked:
- schematic looks correct (and 1:1 taken from the MPC8349 eval board)
- same schematic and code works on the other product - no issues
- CPU has latest revision
- JTAG works in terms of making stop on breakpoints and looking through the registers and memory
- lock-up happens only while stepping through the code
- JTAG connector was re-soldered directly to the vias at BGA - with the same results
- All JTAG and RESET lines are tested with the scope - and signal looks good
Please refer me to anything that might help.
Below is some of the information:
If I set a breakpoint inside the code of inline function rd_addr() @ 0x2A9C0 (as you could see it performs completely legitimate load into r4 from [r31]+0 – i.e. from the location of dobj at the end of the 128MB memory) and then do one step the CPU will stop working. If I put breakpoints in every line it fails to stop at address 0x2A9D0. If I put a single breakpoint at the address 0x2A9D8 it will do a correct read from address 0xA0082424 – allocated SRAM address from CS2.
I don’t see any exceptions coming from DRAM controller, memory is thoroughly tested and do not cause any issues in the normal execution without debugger. Its only when debugger is steps thru the code or even go breakpoint to breakpoint eventually it stops responding. It is in my best understanding that the processor is also stops running since it no longer reacts to any external interrupts to the core. All three HRESET, PRESET and JRESET remain high with no glitches…
- The value of MSR before entering critical section (the code I debug is within this section) is 0xA0B0, after entering it is 0x2030 since I clear EE and CE bits
- Watchdog is not programmed
- If I move from one statement to another statement by setting and clearing break point it works for a while, however in the same way as with single step instruction CPU might lock up if a single step is executed from the breakpoint. However even when the next breakpoint is set down the code CPU can get into the same mode when debugger can no longer stop it
- It is not an issue with this particular board since every board from the batch behaves the same way; we have another very similar board with 8347 which we designed four years ago and this board also exhibits this behavior but infrequently enough to make debugging impossible
- Reset lines seems to be stable so I don't suspect that CPU suddenly resets from the outside signal.
- all reset lines are pulled up to 3.3V via 4.7k 4. While I'm inside the code it is done in critical section. I read MSR register and write it back with two bits - CE (critical interrupts) and EE (external interrupts) set to zero. I do not touch any flags in this register which are responsible for debugging. There are no divisions or floating point operations which could assert an exception.
-When I look at the scope at TDO/TDI/TMS signals it appears that once the PPC is in this state there is no attempt from the debugger to transmit a command over JTAG, it looks like the pattern which goes between PPC and the debugger when PPC is running