I really like the Cortex-M3 but sometimes the hard faults make me crazy. Let me
describe the problem that I see now. If anyone has any good insights, I'd
love to hear them.
I am writing an Ethernet driver for the LPC1766 and I get the hardfault when
returning from the very first ethernet interrupt. Here is the more detailed
sequence of events.
1. A timer interrupt occurs, the driver polls uIP and determines that it needs
to send a packet. It puts the packet into the descriptor list and returns.
2. The packet is small -- an ARP request (42 bytes). And, depending on timing,
may actually complete BEFORE the timer interrupt returns. That is the failure
case -- when the ethernet interrupt is pending on return from the timer
interrupt.
3. When the timer interrupt returns, the final assembly instructions of the
interrupt handler are:
cpsie i
ldr r14, =0xfffffff9
bx r14
4. The pending ethernet interrupt occurs immediately after "cpsie i" and
executes normally as it should.
5. But when the ethernet interrupt returns, that is when the hard fault happens.
The Cortex-M3 reports a "configurable status" hard fault and reports that it is
INVSTATE usage fault. The PC of the error seems to be either the bx or the ldr
instructions -- probably the bx. r14 holds the value 0xfffffff9.
The T bit is set in the PSR and basically looks good other than for the weird
interrupt nesting.
According to the Cortex-M3 manual, INVSTATE is: "Attempt to execute in an
invalid EPSR state. For example, after a BX type instruction has changed state.
This includes states after return from exception including inter-working
states." And "Invalid combination of EPSR and instruction, for reasons other
than UNDEFINED instruction. Return PC points to faulting instruction, with the
invalid state."
Any thoughts? Anyone ever seen this before?
Greg
LPC1766 Hard Fault
Started by ●November 18, 2010
Reply by ●November 18, 20102010-11-18
Hi Greg,
See http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.ddi0337e/index.html The
LR=0xFFFFFFF9 is normal for returning from ISR (it means 'Return to Thread
mode. Exception return gets state from the process stack/PSP. On return
execution uses the process stack/PSP')
Regards,
-daniel
----- Original Message ----
From: Gregory N
To: l...
Sent: Thu, November 18, 2010 10:57:42 PM
Subject: [lpc2000] LPC1766 Hard Fault
I really like the Cortex-M3 but sometimes the hard faults make me crazy. Let me
describe the problem that I see now. If anyone has any good insights, I'd love
to hear them.
I am writing an Ethernet driver for the LPC1766 and I get the hardfault when
returning from the very first ethernet interrupt. Here is the more detailed
sequence of events.
1. A timer interrupt occurs, the driver polls uIP and determines that it needs
to send a packet. It puts the packet into the descriptor list and returns.
2. The packet is small -- an ARP request (42 bytes). And, depending on timing,
may actually complete BEFORE the timer interrupt returns. That is the failure
case -- when the ethernet interrupt is pending on return from the timer
interrupt.
3. When the timer interrupt returns, the final assembly instructions of the
interrupt handler are:
cpsie i
ldr r14, =0xfffffff9
bx r14
4. The pending ethernet interrupt occurs immediately after "cpsie i" and
executes normally as it should.
5. But when the ethernet interrupt returns, that is when the hard fault
happens. The Cortex-M3 reports a "configurable status" hard fault and reports
that it is INVSTATE usage fault. The PC of the error seems to be either the bx
or the ldr instructions -- probably the bx. r14 holds the value 0xfffffff9.
The T bit is set in the PSR and basically looks good other than for the weird
interrupt nesting.
According to the Cortex-M3 manual, INVSTATE is: "Attempt to execute in an
invalid EPSR state. For example, after a BX type instruction has changed state.
This includes states after return from exception including inter-working
states." And "Invalid combination of EPSR and instruction, for reasons other
than UNDEFINED instruction. Return PC points to faulting instruction, with the
invalid state."
Any thoughts? Anyone ever seen this before?
Greg
See http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.ddi0337e/index.html The
LR=0xFFFFFFF9 is normal for returning from ISR (it means 'Return to Thread
mode. Exception return gets state from the process stack/PSP. On return
execution uses the process stack/PSP')
Regards,
-daniel
----- Original Message ----
From: Gregory N
To: l...
Sent: Thu, November 18, 2010 10:57:42 PM
Subject: [lpc2000] LPC1766 Hard Fault
I really like the Cortex-M3 but sometimes the hard faults make me crazy. Let me
describe the problem that I see now. If anyone has any good insights, I'd love
to hear them.
I am writing an Ethernet driver for the LPC1766 and I get the hardfault when
returning from the very first ethernet interrupt. Here is the more detailed
sequence of events.
1. A timer interrupt occurs, the driver polls uIP and determines that it needs
to send a packet. It puts the packet into the descriptor list and returns.
2. The packet is small -- an ARP request (42 bytes). And, depending on timing,
may actually complete BEFORE the timer interrupt returns. That is the failure
case -- when the ethernet interrupt is pending on return from the timer
interrupt.
3. When the timer interrupt returns, the final assembly instructions of the
interrupt handler are:
cpsie i
ldr r14, =0xfffffff9
bx r14
4. The pending ethernet interrupt occurs immediately after "cpsie i" and
executes normally as it should.
5. But when the ethernet interrupt returns, that is when the hard fault
happens. The Cortex-M3 reports a "configurable status" hard fault and reports
that it is INVSTATE usage fault. The PC of the error seems to be either the bx
or the ldr instructions -- probably the bx. r14 holds the value 0xfffffff9.
The T bit is set in the PSR and basically looks good other than for the weird
interrupt nesting.
According to the Cortex-M3 manual, INVSTATE is: "Attempt to execute in an
invalid EPSR state. For example, after a BX type instruction has changed state.
This includes states after return from exception including inter-working
states." And "Invalid combination of EPSR and instruction, for reasons other
than UNDEFINED instruction. Return PC points to faulting instruction, with the
invalid state."
Any thoughts? Anyone ever seen this before?
Greg
Reply by ●November 19, 20102010-11-19
On Thu, Nov 18, 2010 at 8:27 PM, Gregory N wrote:
> I really like the Cortex-M3 but sometimes the hard faults make me crazy.
> Let me describe the problem that I see now. If anyone has any good insights,
> I'd love to hear them.
>
> I am writing an Ethernet driver for the LPC1766 and I get the hardfault
> when returning from the very first ethernet interrupt. Here is the more
> detailed sequence of events.
>
> 1. A timer interrupt occurs, the driver polls uIP and determines that it
> needs to send a packet. It puts the packet into the descriptor list and
> returns.
>
> 2. The packet is small -- an ARP request (42 bytes). And, depending on
> timing, may actually complete BEFORE the timer interrupt returns. That is
> the failure case -- when the ethernet interrupt is pending on return from
> the timer interrupt.
>
> 3. When the timer interrupt returns, the final assembly instructions of the
> interrupt handler are:
>
> cpsie i
> ldr r14, =0xfffffff9
> bx r14
>
> 4. The pending ethernet interrupt occurs immediately after "cpsie i" and
> executes normally as it should.
>
> 5. But when the ethernet interrupt returns, that is when the hard fault
> happens. The Cortex-M3 reports a "configurable status" hard fault and
> reports that it is INVSTATE usage fault. The PC of the error seems to be
> either the bx or the ldr instructions -- probably the bx. r14 holds the
> value 0xfffffff9.
>
> The T bit is set in the PSR and basically looks good other than for the
> weird interrupt nesting.
>
> According to the Cortex-M3 manual, INVSTATE is: "Attempt to execute in an
> invalid EPSR state. For example, after a BX type instruction has changed
> state. This includes states after return from exception including
> inter-working states." And "Invalid combination of EPSR and instruction, for
> reasons other than UNDEFINED instruction. Return PC points to faulting
> instruction, with the invalid state."
>
> Any thoughts? Anyone ever seen this before?
>
> Greg
>
Just to give you a different perspective. I had a similar problem w.r.t to
hard fault and at first it seemed very crazy. In my case I was implementing
a simple UART driver module and was trying to use UART3 (If I remember it
correctly). The hard fault occurred every time I tried access the UART3
registers... Changing to UART0 registers it worked fine (did not FAULT).
After carefully reading the User Manual I realized that the UART3 clock is
not enabled by default and hence the core issued a fault. I just enabled the
UART3 clock everything worked fine.
Hope this helps. All the best
--
Warm regards
Ashwin
NGX Technologies Pvt. Ltd.
http://shop.ngxtechnologies.com/
> I really like the Cortex-M3 but sometimes the hard faults make me crazy.
> Let me describe the problem that I see now. If anyone has any good insights,
> I'd love to hear them.
>
> I am writing an Ethernet driver for the LPC1766 and I get the hardfault
> when returning from the very first ethernet interrupt. Here is the more
> detailed sequence of events.
>
> 1. A timer interrupt occurs, the driver polls uIP and determines that it
> needs to send a packet. It puts the packet into the descriptor list and
> returns.
>
> 2. The packet is small -- an ARP request (42 bytes). And, depending on
> timing, may actually complete BEFORE the timer interrupt returns. That is
> the failure case -- when the ethernet interrupt is pending on return from
> the timer interrupt.
>
> 3. When the timer interrupt returns, the final assembly instructions of the
> interrupt handler are:
>
> cpsie i
> ldr r14, =0xfffffff9
> bx r14
>
> 4. The pending ethernet interrupt occurs immediately after "cpsie i" and
> executes normally as it should.
>
> 5. But when the ethernet interrupt returns, that is when the hard fault
> happens. The Cortex-M3 reports a "configurable status" hard fault and
> reports that it is INVSTATE usage fault. The PC of the error seems to be
> either the bx or the ldr instructions -- probably the bx. r14 holds the
> value 0xfffffff9.
>
> The T bit is set in the PSR and basically looks good other than for the
> weird interrupt nesting.
>
> According to the Cortex-M3 manual, INVSTATE is: "Attempt to execute in an
> invalid EPSR state. For example, after a BX type instruction has changed
> state. This includes states after return from exception including
> inter-working states." And "Invalid combination of EPSR and instruction, for
> reasons other than UNDEFINED instruction. Return PC points to faulting
> instruction, with the invalid state."
>
> Any thoughts? Anyone ever seen this before?
>
> Greg
>
Just to give you a different perspective. I had a similar problem w.r.t to
hard fault and at first it seemed very crazy. In my case I was implementing
a simple UART driver module and was trying to use UART3 (If I remember it
correctly). The hard fault occurred every time I tried access the UART3
registers... Changing to UART0 registers it worked fine (did not FAULT).
After carefully reading the User Manual I realized that the UART3 clock is
not enabled by default and hence the core issued a fault. I just enabled the
UART3 clock everything worked fine.
Hope this helps. All the best
--
Warm regards
Ashwin
NGX Technologies Pvt. Ltd.
http://shop.ngxtechnologies.com/
Reply by ●November 19, 20102010-11-19
Good work with that problem. Charles AE5EW
--- In l..., Ashwin Athani wrote:
>
> On Thu, Nov 18, 2010 at 8:27 PM, Gregory N wrote:
>
> >
> >
> > I really like the Cortex-M3 but sometimes the hard faults make me crazy.
> > Let me describe the problem that I see now. If anyone has any good insights,
> > I'd love to hear them.
> >
> > I am writing an Ethernet driver for the LPC1766 and I get the hardfault
> > when returning from the very first ethernet interrupt. Here is the more
> > detailed sequence of events.
> >
> > 1. A timer interrupt occurs, the driver polls uIP and determines that it
> > needs to send a packet. It puts the packet into the descriptor list and
> > returns.
> >
> > 2. The packet is small -- an ARP request (42 bytes). And, depending on
> > timing, may actually complete BEFORE the timer interrupt returns. That is
> > the failure case -- when the ethernet interrupt is pending on return from
> > the timer interrupt.
> >
> > 3. When the timer interrupt returns, the final assembly instructions of the
> > interrupt handler are:
> >
> > cpsie i
> > ldr r14, =0xfffffff9
> > bx r14
> >
> > 4. The pending ethernet interrupt occurs immediately after "cpsie i" and
> > executes normally as it should.
> >
> > 5. But when the ethernet interrupt returns, that is when the hard fault
> > happens. The Cortex-M3 reports a "configurable status" hard fault and
> > reports that it is INVSTATE usage fault. The PC of the error seems to be
> > either the bx or the ldr instructions -- probably the bx. r14 holds the
> > value 0xfffffff9.
> >
> > The T bit is set in the PSR and basically looks good other than for the
> > weird interrupt nesting.
> >
> > According to the Cortex-M3 manual, INVSTATE is: "Attempt to execute in an
> > invalid EPSR state. For example, after a BX type instruction has changed
> > state. This includes states after return from exception including
> > inter-working states." And "Invalid combination of EPSR and instruction, for
> > reasons other than UNDEFINED instruction. Return PC points to faulting
> > instruction, with the invalid state."
> >
> > Any thoughts? Anyone ever seen this before?
> >
> > Greg
> > Just to give you a different perspective. I had a similar problem w.r.t to
> hard fault and at first it seemed very crazy. In my case I was implementing
> a simple UART driver module and was trying to use UART3 (If I remember it
> correctly). The hard fault occurred every time I tried access the UART3
> registers... Changing to UART0 registers it worked fine (did not FAULT).
> After carefully reading the User Manual I realized that the UART3 clock is
> not enabled by default and hence the core issued a fault. I just enabled the
> UART3 clock everything worked fine.
>
> Hope this helps. All the best
>
> --
> Warm regards
> Ashwin
> NGX Technologies Pvt. Ltd.
> http://shop.ngxtechnologies.com/
>
--- In l..., Ashwin Athani wrote:
>
> On Thu, Nov 18, 2010 at 8:27 PM, Gregory N wrote:
>
> >
> >
> > I really like the Cortex-M3 but sometimes the hard faults make me crazy.
> > Let me describe the problem that I see now. If anyone has any good insights,
> > I'd love to hear them.
> >
> > I am writing an Ethernet driver for the LPC1766 and I get the hardfault
> > when returning from the very first ethernet interrupt. Here is the more
> > detailed sequence of events.
> >
> > 1. A timer interrupt occurs, the driver polls uIP and determines that it
> > needs to send a packet. It puts the packet into the descriptor list and
> > returns.
> >
> > 2. The packet is small -- an ARP request (42 bytes). And, depending on
> > timing, may actually complete BEFORE the timer interrupt returns. That is
> > the failure case -- when the ethernet interrupt is pending on return from
> > the timer interrupt.
> >
> > 3. When the timer interrupt returns, the final assembly instructions of the
> > interrupt handler are:
> >
> > cpsie i
> > ldr r14, =0xfffffff9
> > bx r14
> >
> > 4. The pending ethernet interrupt occurs immediately after "cpsie i" and
> > executes normally as it should.
> >
> > 5. But when the ethernet interrupt returns, that is when the hard fault
> > happens. The Cortex-M3 reports a "configurable status" hard fault and
> > reports that it is INVSTATE usage fault. The PC of the error seems to be
> > either the bx or the ldr instructions -- probably the bx. r14 holds the
> > value 0xfffffff9.
> >
> > The T bit is set in the PSR and basically looks good other than for the
> > weird interrupt nesting.
> >
> > According to the Cortex-M3 manual, INVSTATE is: "Attempt to execute in an
> > invalid EPSR state. For example, after a BX type instruction has changed
> > state. This includes states after return from exception including
> > inter-working states." And "Invalid combination of EPSR and instruction, for
> > reasons other than UNDEFINED instruction. Return PC points to faulting
> > instruction, with the invalid state."
> >
> > Any thoughts? Anyone ever seen this before?
> >
> > Greg
> > Just to give you a different perspective. I had a similar problem w.r.t to
> hard fault and at first it seemed very crazy. In my case I was implementing
> a simple UART driver module and was trying to use UART3 (If I remember it
> correctly). The hard fault occurred every time I tried access the UART3
> registers... Changing to UART0 registers it worked fine (did not FAULT).
> After carefully reading the User Manual I realized that the UART3 clock is
> not enabled by default and hence the core issued a fault. I just enabled the
> UART3 clock everything worked fine.
>
> Hope this helps. All the best
>
> --
> Warm regards
> Ashwin
> NGX Technologies Pvt. Ltd.
> http://shop.ngxtechnologies.com/
>
Reply by ●November 19, 20102010-11-19
On Thu, Nov 18, 2010 at 9:57 AM, Gregory N wrote:
> I really like the Cortex-M3 but sometimes the hard faults make me crazy.
> Let me describe the problem that I see now. If anyone has any good insights,
> I'd love to hear them.
>
> I am writing an Ethernet driver for the LPC1766 and I get the hardfault
> when returning from the very first ethernet interrupt. Here is the more
> detailed sequence of events.
>
> I really have no idea if it's related, but since you mention the fault
occurs on the very first int....
There is that errata about the first packet not being sent properly, and
the TxConsumeIndex not updating properly.
Can you try sending one dummy packet without ints first?
carl
--------------------
Henry Carl Ott N2RVQ h...@gmail.com
> I really like the Cortex-M3 but sometimes the hard faults make me crazy.
> Let me describe the problem that I see now. If anyone has any good insights,
> I'd love to hear them.
>
> I am writing an Ethernet driver for the LPC1766 and I get the hardfault
> when returning from the very first ethernet interrupt. Here is the more
> detailed sequence of events.
>
> I really have no idea if it's related, but since you mention the fault
occurs on the very first int....
There is that errata about the first packet not being sent properly, and
the TxConsumeIndex not updating properly.
Can you try sending one dummy packet without ints first?
carl
--------------------
Henry Carl Ott N2RVQ h...@gmail.com
Reply by ●November 19, 20102010-11-19
Thanks everyone for your replies. You all gave me some good things to think
about. I eventually did come up with a fix by changing my interrupt handling
logic.
It was:
> cpsie i
> ldr r14, =0xfffffff9
> bx r14
It I change this to:
ldr r14, =0xfffffff9
cpsie i
bx r14
I may be sweeping a few things under the rug. I believe that this works because the bx r14 now happens in the pipeline after the cpsie BEFORE interrupts are really re-enabled so that there is no nested interrupt.
I would like to say this was solved due to my keen insight into the issues. Unfortunately, the truth is that it was number 201 of several half baked hunches that finally paid off.
Greg
It was:
> cpsie i
> ldr r14, =0xfffffff9
> bx r14
It I change this to:
ldr r14, =0xfffffff9
cpsie i
bx r14
I may be sweeping a few things under the rug. I believe that this works because the bx r14 now happens in the pipeline after the cpsie BEFORE interrupts are really re-enabled so that there is no nested interrupt.
I would like to say this was solved due to my keen insight into the issues. Unfortunately, the truth is that it was number 201 of several half baked hunches that finally paid off.
Greg
Reply by ●November 19, 20102010-11-19
Hi, Carl,
> There is that errata about the first packet not being sent properly, and
> the TxConsumeIndex not updating properly.
I saw this one. My understanding is that the packet does get sent properly, but the the consume index doesn't get updated (and, I presume the first interrupt is missing???). Then on the second transmit, the consume index is supposed to jump up by 2 then be correct after that. Very strange.
Actually, I have been monitoring the produce and consume indexes on my LPC1766 and I don't seem to have the errata??? On the first packet, the produce index gets incremented 0->1 and then the consume index gets increment 0->1 very, very soon afterward.
I actually did come up with a fix for the hard fault (different email in this thread), but I appreciate you help.
Greg
> There is that errata about the first packet not being sent properly, and
> the TxConsumeIndex not updating properly.
I saw this one. My understanding is that the packet does get sent properly, but the the consume index doesn't get updated (and, I presume the first interrupt is missing???). Then on the second transmit, the consume index is supposed to jump up by 2 then be correct after that. Very strange.
Actually, I have been monitoring the produce and consume indexes on my LPC1766 and I don't seem to have the errata??? On the first packet, the produce index gets incremented 0->1 and then the consume index gets increment 0->1 very, very soon afterward.
I actually did come up with a fix for the hard fault (different email in this thread), but I appreciate you help.
Greg
