• State Not Answered
  • Locked Locked
  • Replies 2 replies
  • Subscribers 345 subscribers
  • Views 3645 views
  • Users 0 members are here
Options
Related
How was your experience today?
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Yet another processor crash!

Chris Williams

Yes, my ARM cortex M3 is crashing, whats new?

Well, after 3 weeks of debug  I am no closer to an answer, so I hope you will not mind if I list what I have tried and see if anybody has a flash of inspiration?

The setup:

Bare bones LPC1788 ARM Cortex M3 with graphics LCD. Code in External FLASH, LCD memory external RAM, stack in internal RAM, vectors in internal RAM.

Runs fine most of the time.

Running time tick interrupt code in internal RAM (increments a counter). This seems to interact with some main loop code and the processor crashes. Looks like it crashes when a particular part of the main loop meets the interrupt.

There is code in internal RAM for all the traps, none of which are called, including the watchdog trap.

A watchdog reset DOES work.

The xtal oscillator is still running.

The LCD is clocking correctly but displays a single colour. There is no activity on the external memory bus so the LCD has stopped accessing it (or is blocked).

The Jtag debugger works fine up until this point, but the fails when the processor crashes. It says it can't access the debug port.

So, it looks as thought the processor is locked up in some way. I have protected the EMC registers (setup for external pins) with the MMU but no difference.

Where can my processor have gone? How did it get there?

Any suggestions much appreciated.

Chris Williams.

  • 0

    The few times I've had this happen is either:

    • when I was failing to clear interrupt pending, so the core was just stuck in an infinite loop of taking the same interrupt over and over again (although that doesn't explain why your JTAG isn't working - it should be capable of halting in an interrupt handler).
    • when I managed to corrupt the vector table so that taking a vector faulted because it was pointing at a dead location, resulting in another vector jump to the fault handler, which faulted instantly, which jumped to the fault handler, etc. In this scenario the core never manages to complete taking an exception, so even JTAG has problems interrupting as the core never architecturally reaches a point where it can stop.

    This was a while ago on an ARM7 MCU, not on a Cortex-M however, but I imagine a similar set of circumstances are possible.

    HTH,
    Pete

  • 0

    Its the fact that Jtag has stopped that I think holds the key. I have moved the trap vectors from start of RAM to end of RAM to see if overwrite wight have been a problem but that did not help.

    I have also used the MMU to protect various ranges from access (I have an MMU trap) but no help.

    However, I can see that a problem with the trap vectors COULD cause the problems I am seeing.

    It occurred  to me that having the traps in external FLASH could cause this problem (if you can't access external memory) so I moved them into internal RAM which should always be available.

    Chris.