topic Re: Processor crash in LPC Microcontrollers

Processor crash

lpcware — Wed, 15 Jun 2016 18:07:47 GMT

Content originally posted in LPCWare by chris_williams_uk on Thu Nov 26 01:59:48 MST 2015
Hi,

I am sure you get lots of 'processor crash' problems, BUT I think this one is different:

The processor is the LPC1788 (ARM cortex M3) running bare bones with attached TFT LCD.

An interrupt causes it to crash at some point, randomly, nothing unusual there.

HOWEVER,

The processor seems to have completely died.

Non of the traps have been called, they are all monitored.
The main oscillator is running.
The LCD which runs from external memory has a blank single colour screen. When I look at the external memory bus it is stopped, so the LCD is still trying to run, but not accessing external memory.
The watchdog trap is not called, however, if watchdog is set to reset, that will recover.
The Jtag debug port crashes. It works fine up until the processor crash and then the debugger fails to access the processor.

So, the processor sems to be completely stopped.

Does anybody know what state the processor is in? and how it might have got there?

Any ideas appreciated.

Regards, Chris.

Re: Processor crash

lpcware — Wed, 15 Jun 2016 18:07:47 GMT

Content originally posted in LPCWare by R2D2 on Thu Nov 26 02:27:56 MST 2015

Quote: chris_williams_uk

Any ideas appreciated.

Did you boot into ISP already?

Re: Processor crash

lpcware — Wed, 15 Jun 2016 18:07:48 GMT

Content originally posted in LPCWare by starblue on Thu Nov 26 03:03:45 MST 2015
There is Lockup state (see ARMv7-M Architecture Reference Manual, DDI 0403 for details), but as far as I understand Debug should still work.

Re: Processor crash

lpcware — Wed, 15 Jun 2016 18:07:49 GMT

Content originally posted in LPCWare by vtw.433e on Thu Nov 26 03:09:50 MST 2015
Has it gone to sleep? That would explain what you are seeing.

Re: Processor crash

lpcware — Wed, 15 Jun 2016 18:07:49 GMT

Content originally posted in LPCWare by chris_williams_uk on Thu Nov 26 03:14:07 MST 2015
Good idea, I had not thought of that.
I have just checked. I try sending '?' to the serial port which is I think the sync character and I get no reply. Also, should the Jtag still work in ISP?

Regards,

Chris.

Re: Processor crash

lpcware — Wed, 15 Jun 2016 18:07:50 GMT

Content originally posted in LPCWare by R2D2 on Thu Nov 26 03:31:03 MST 2015

Quote: chris_williams_uk
Good idea, I had not thought of that.
I have just checked. I try sending '?' to the serial port which is I think the sync character and I get no reply. Also, should the Jtag still work in ISP?

Nice theory :D

Unfortunately it's possible that you are in ISP and debugging isn't working :((

I would suggest to use FlashMagic after booting into ISP. If UART-ISP isn't working your MCU is dead...

Probably you have more than 1 board, so testing UART-ISP / FlashMagic with a working board should show a different behaviour.

Usually the MCU is dead (or CRP locked) if ISP isn't working...

Note: IIRC there's a baud rate issue and you can't use ISP baudrates > 57600...

Re: Processor crash

lpcware — Wed, 15 Jun 2016 18:07:50 GMT

Content originally posted in LPCWare by mysepp on Thu Nov 26 04:36:40 MST 2015
What does "The processor seems to have completely died." mean?
What does "So, the processor sems to be completely stopped." mean?
Works again after reset? Till next time this happens? Or does it not respond any more at all?
Or is the controller not usable any more at all?

Re: Processor crash

lpcware — Wed, 15 Jun 2016 18:07:51 GMT

Content originally posted in LPCWare by chris_williams_uk on Thu Nov 26 08:04:58 MST 2015
Processor seems to have completely died. It is not running the code from external flash, it has not called any traps, it will not respond to the Jtag debugger.
After a reset it restarts with no problems. I can then cause the fault again by running a particular bit of code when it interacts with an interrupt routine.
This does NOT permanently damage the processor.

So, as I said the processor seems to have stopped. The fact that the Jtag also fails seems to be important in this, I just don't know how.

Chris.

Re: Processor crash

lpcware — Wed, 15 Jun 2016 18:07:52 GMT

Content originally posted in LPCWare by chris_williams_uk on Thu Nov 26 08:45:33 MST 2015

Quote: vtw.433e
Has it gone to sleep? That would explain what you are seeing.

Good idea. However I have just checked and I have put MMU protection over all the sys control registers, so it should give an MMU fault if it tries to write to the power down registers.

Thanks for the idea.

Chris.

Re: Processor crash

lpcware — Wed, 15 Jun 2016 18:07:52 GMT

Content originally posted in LPCWare by chris_williams_uk on Thu Nov 26 09:07:16 MST 2015

Quote: R2D2

Quote: chris_williams_uk

Any ideas appreciated.

Did you boot into ISP already?

I thought I would do a further test.

I have just booted into ISP and then run the debugger. It connects with no problem and I can halt and step with no problem, so I don't think that is the mode I am getting into.

Regards,

Chris.

Re: Processor crash

lpcware — Wed, 15 Jun 2016 18:07:53 GMT

Content originally posted in LPCWare by MikeSimmonds on Thu Nov 26 18:20:09 MST 2015
Do you configure for Ethernet?

If the EMAC RX and (or?) TX clocks are not correct the dubugger stops (I was using SWD)
The problem does not arise if you are not using Ethernet. The are a few threads on this if you
do use Ethernet.

Mike.

Re: Processor crash

lpcware — Wed, 15 Jun 2016 18:07:53 GMT

Content originally posted in LPCWare by starblue on Fri Nov 27 01:34:44 MST 2015

Quote: MikeSimmonds
If the EMAC RX and (or?) TX clocks are not correct the debugger stops (I was using SWD)

Yes, it could be stalled when trying to access some peripheral register when the peripheral is without clock.
Similar things could happen with the realtime clock, I think.

Re: Processor crash

lpcware — Wed, 15 Jun 2016 18:07:54 GMT

Content originally posted in LPCWare by R2D2 on Fri Nov 27 02:28:32 MST 2015

Quote: chris_williams_uk
An interrupt causes it to crash at some point, randomly, nothing unusual there.

Stack corruption?

Quote:
Possible reasons for a Hard Fault include:

- Trying to read or write to an on-chip peripheral that is powered down or not being clocked
- Stack corruption - for example, overwriting the stack with data
- Calling a function pointer with an invalid address

Re: Processor crash

lpcware — Wed, 15 Jun 2016 18:07:55 GMT

Content originally posted in LPCWare by chris_williams_uk on Fri Nov 27 03:03:06 MST 2015

Quote: MikeSimmonds
Do you configure for Ethernet?

If the EMAC RX and (or?) TX clocks are not correct the dubugger stops (I was using SWD)
The problem does not arise if you are not using Ethernet. The are a few threads on this if you
do use Ethernet.

Mike.

Yes, I do use Ethernet.

Its actually working quite hard at this point.

Can you point me to a thread to look at?

Chris.

Re: Processor crash

lpcware — Wed, 15 Jun 2016 18:07:55 GMT

Content originally posted in LPCWare by chris_williams_uk on Fri Nov 27 03:08:27 MST 2015

Quote: R2D2

Quote: chris_williams_uk
An interrupt causes it to crash at some point, randomly, nothing unusual there.

Stack corruption?

I agree, stack corruption could be a problem, BUT we should then get a hard fault?

You can get a problem if the hard fault handler then tries to stack. So, I have declared all my trap functions as __attribute__ ((naked))

I have checked the assembler and I can see that there is no stacking in the traps. Unfortunately I still get no trap message!

As an aside: How do you get a trap message when you can't call any routines (no stack)?

I use a single write to the serial port TX register. Even if my LCD has stopped and I can't run any routines, a single character too the serial port register will still indicate I have called the trap routine.

Chris.

Re: Processor crash

lpcware — Wed, 15 Jun 2016 18:07:56 GMT

Content originally posted in LPCWare by R2D2 on Fri Nov 27 04:23:48 MST 2015

Quote: chris_williams_uk

I agree, stack corruption could be a problem, BUT we should then get a hard fault?

You can get a problem if the hard fault handler then tries to stack. So, I have declared all my trap functions as __attribute__ ((naked))

Even a naked hard fault handler with simple LED asm code isn't always executed :O

So without debugger and without fault handler your last chance is to change your code / project settings to find your problem.

I would guess it's a RAM usage problem, somewhere someone is overwriting something :((

Re: Processor crash

lpcware — Wed, 15 Jun 2016 18:07:57 GMT

Content originally posted in LPCWare by MikeSimmonds on Fri Nov 27 22:35:04 MST 2015
If your Ethernet is configured and working, then the issue I mentioned does not apply.

Mike.