Hello everybody,
I have a weird problem with the Ethernet interface of the LPC23xx series
(specifically, I am using an LPC2388, plus a SMSC LAN8720 physical). The
Ethernet interface is configured in a very similar way as in AN10799. For the
(DMA) descriptor arrays, I have 6 descriptors for reception and 4 descriptors
for transmission. All frames are 1536 bytes long (each descriptor references a
full Ethernet frame).
Now, the problem is: sometimes TxConsumeIndex is not updated anymore. This is
incidental; I can sent a thousand packets before this happens. The basic
"transmit loop" is: check whether there is space it the queue, write the packet,
set the control word, and update TxProduceIndex. The hardware will update
TxConsumeIndex.
I cannot tell whether it is just TxConsumeIndex that is not updated (but the
packets are sent regardless), or whether the packets were never sent over the
wire.
Now the circumstances of the blocking are what makes it curious. Since I have 4
descriptors, both TxConsumeIndex and TxProduceIndex cycle from 0 to 3. But when
the transmit queue blocks, TxConsumeIndex is 2 and TxProduceIndex is 1 (at this
point, the transmit queue is full). No amount of waiting will cause
TxConsumeIndex to increment to 3, then cycle back to 0, etc. The transmit status
information words for the items in the transmit queue are all zero.
If this is a silly programming error on my part, I would expect that the
transmit queue would block at any value for TxConsumeIndex, but it only blocks
when it is 2. I saw the errata Ethernet.4 ("Ethernet TxConsumeIndex register
does not update correctly after the first frame is sent") in the errata sheet,
but I believe this does not apply to this particular case.
I currently "solve" the problem by resetting the transmit logic in the MAC.
However, that causes me to loose the 3 packets in the transmit queue. (I could
probably add them again by merely setting the control words and updating
TxProduceIndex.)
I think that I am overlooking something. Can anyone shine a light on this?
Thanks in advance,
Thiadmer
LPC23xx Ethernet transmission blocks
Started by ●September 21, 2010
Reply by ●September 22, 20102010-09-22
Hello everyone,
Would you believe that I actually tried to search the message forums before posting my message. It was only after I sent it that I thought of using the word "stall" instead of "block" and search again. Low and behold: this problem was reported earlier: see messages #34477 and #34487.
Summarizing the three messages: the problem occurs when the transmit queue fills up while TxConsumeIndex = 2 (so TxProduceIndex is 1, in this case). The effect is that the transmit queue stalls, and will not resume unless the transmit logic is reset. This is less likely to occur with a large transmit queue, and less likely when transmitting packets at a slow pace.
Fortunately, there is a simple work-around: in the transmit descriptor's control word, set the interrupt bit (bit 31, in examples from NXP, this bit is defined in a macro called TCTRL_INT or EMAC_TCTRL_INT). You do not have to handle the interrupt, or do anything else. Just setting the bit avoids the problem.
Acknowledgements:
Thanks to Sven Dreichbach (message #34487) for his precise description of the symptoms, convincing me that this is an LPC23xx errata (rather than a programming error). Thanks to Sven Dreichbach and Jorge Polar (message #34477) for the observation that the problem only occurred when sending out packets quickly (something that was true in my case as well, but which I had not paid attention to).
And thanks to the analysis at "http://www.utasker.com/forum/index.php?topic9.0". This post hinted at an unexpected correlation between the updating of TxConsumeIndex and the interrupt bit.
Regards,
Thiadmer Riemersma
Would you believe that I actually tried to search the message forums before posting my message. It was only after I sent it that I thought of using the word "stall" instead of "block" and search again. Low and behold: this problem was reported earlier: see messages #34477 and #34487.
Summarizing the three messages: the problem occurs when the transmit queue fills up while TxConsumeIndex = 2 (so TxProduceIndex is 1, in this case). The effect is that the transmit queue stalls, and will not resume unless the transmit logic is reset. This is less likely to occur with a large transmit queue, and less likely when transmitting packets at a slow pace.
Fortunately, there is a simple work-around: in the transmit descriptor's control word, set the interrupt bit (bit 31, in examples from NXP, this bit is defined in a macro called TCTRL_INT or EMAC_TCTRL_INT). You do not have to handle the interrupt, or do anything else. Just setting the bit avoids the problem.
Acknowledgements:
Thanks to Sven Dreichbach (message #34487) for his precise description of the symptoms, convincing me that this is an LPC23xx errata (rather than a programming error). Thanks to Sven Dreichbach and Jorge Polar (message #34477) for the observation that the problem only occurred when sending out packets quickly (something that was true in my case as well, but which I had not paid attention to).
And thanks to the analysis at "http://www.utasker.com/forum/index.php?topic9.0". This post hinted at an unexpected correlation between the updating of TxConsumeIndex and the interrupt bit.
Regards,
Thiadmer Riemersma
Reply by ●September 22, 20102010-09-22
Hi Thiadmer,
Thank you for a very well-written post. This is exactly the kind of information
that makes a forum like this valuable.
Best regards,
Norman
________________________________
From: compuphase2
To: l...
Sent: Wed, September 22, 2010 3:14:31 AM
Subject: [lpc2000] Re: LPC23xx Ethernet transmission stalls
Hello everyone,
Would you believe that I actually tried to search the message forums before
posting my message. It was only after I sent it that I thought of using the word
"stall" instead of "block" and search again. Low and behold: this problem was
reported earlier: see messages #34477 and #34487.
Summarizing the three messages: the problem occurs when the transmit queue fills
up while TxConsumeIndex = 2 (so TxProduceIndex is 1, in this case). The effect
is that the transmit queue stalls, and will not resume unless the transmit logic
is reset. This is less likely to occur with a large transmit queue, and less
likely when transmitting packets at a slow pace.
Fortunately, there is a simple work-around: in the transmit descriptor's control
word, set the interrupt bit (bit 31, in examples from NXP, this bit is defined
in a macro called TCTRL_INT or EMAC_TCTRL_INT). You do not have to handle the
interrupt, or do anything else. Just setting the bit avoids the problem.
Acknowledgements:
Thanks to Sven Dreichbach (message #34487) for his precise description of the
symptoms, convincing me that this is an LPC23xx errata (rather than a
programming error). Thanks to Sven Dreichbach and Jorge Polar (message #34477)
for the observation that the problem only occurred when sending out packets
quickly (something that was true in my case as well, but which I had not paid
attention to).
And thanks to the analysis at
"http://www.utasker.com/forum/index.php?topic9.0". This post hinted at an
unexpected correlation between the updating of TxConsumeIndex and the interrupt
bit.
Regards,
Thiadmer Riemersma
Thank you for a very well-written post. This is exactly the kind of information
that makes a forum like this valuable.
Best regards,
Norman
________________________________
From: compuphase2
To: l...
Sent: Wed, September 22, 2010 3:14:31 AM
Subject: [lpc2000] Re: LPC23xx Ethernet transmission stalls
Hello everyone,
Would you believe that I actually tried to search the message forums before
posting my message. It was only after I sent it that I thought of using the word
"stall" instead of "block" and search again. Low and behold: this problem was
reported earlier: see messages #34477 and #34487.
Summarizing the three messages: the problem occurs when the transmit queue fills
up while TxConsumeIndex = 2 (so TxProduceIndex is 1, in this case). The effect
is that the transmit queue stalls, and will not resume unless the transmit logic
is reset. This is less likely to occur with a large transmit queue, and less
likely when transmitting packets at a slow pace.
Fortunately, there is a simple work-around: in the transmit descriptor's control
word, set the interrupt bit (bit 31, in examples from NXP, this bit is defined
in a macro called TCTRL_INT or EMAC_TCTRL_INT). You do not have to handle the
interrupt, or do anything else. Just setting the bit avoids the problem.
Acknowledgements:
Thanks to Sven Dreichbach (message #34487) for his precise description of the
symptoms, convincing me that this is an LPC23xx errata (rather than a
programming error). Thanks to Sven Dreichbach and Jorge Polar (message #34477)
for the observation that the problem only occurred when sending out packets
quickly (something that was true in my case as well, but which I had not paid
attention to).
And thanks to the analysis at
"http://www.utasker.com/forum/index.php?topic9.0". This post hinted at an
unexpected correlation between the updating of TxConsumeIndex and the interrupt
bit.
Regards,
Thiadmer Riemersma
Reply by ●October 11, 20102010-10-11
I have the same problem with the Ethernet interface of the LPC23xx series that
Thiadmer described.
(specifically, I am using an LPC2468).
I have 7 descriptors for reception and 3 descriptors for transmission. All frames are 1536 bytes long .
I tried the work-around which Thiadmer gived,in the transmit descriptor's controlword, set the interrupt bit (bit 31, in examples from NXP, this bit is definedin a macro called TCTRL_INT or EMAC_TCTRL_INT),
but no use.The tranmission stalls issue still happened after transmit about 4~6 thosand packets.
I have been faced this problem for two month already.
Does anyone have another work-around?
Please help me!!
Thanks a lot.
poki
--- In l..., Norman Felder wrote:
>
> Hi Thiadmer,
>
> Thank you for a very well-written post. This is exactly the kind of information
> that makes a forum like this valuable.
>
> Best regards,
> Norman
>
> ________________________________
> From: compuphase2
> To: l...
> Sent: Wed, September 22, 2010 3:14:31 AM
> Subject: [lpc2000] Re: LPC23xx Ethernet transmission stalls
>
>
> Hello everyone,
>
> Would you believe that I actually tried to search the message forums before
> posting my message. It was only after I sent it that I thought of using the word
> "stall" instead of "block" and search again. Low and behold: this problem was
> reported earlier: see messages #34477 and #34487.
>
> Summarizing the three messages: the problem occurs when the transmit queue fills
> up while TxConsumeIndex = 2 (so TxProduceIndex is 1, in this case). The effect
> is that the transmit queue stalls, and will not resume unless the transmit logic
> is reset. This is less likely to occur with a large transmit queue, and less
> likely when transmitting packets at a slow pace.
>
> Fortunately, there is a simple work-around: in the transmit descriptor's control
> word, set the interrupt bit (bit 31, in examples from NXP, this bit is defined
> in a macro called TCTRL_INT or EMAC_TCTRL_INT). You do not have to handle the
> interrupt, or do anything else. Just setting the bit avoids the problem.
>
> Acknowledgements:
> Thanks to Sven Dreichbach (message #34487) for his precise description of the
> symptoms, convincing me that this is an LPC23xx errata (rather than a
> programming error). Thanks to Sven Dreichbach and Jorge Polar (message #34477)
> for the observation that the problem only occurred when sending out packets
> quickly (something that was true in my case as well, but which I had not paid
> attention to).
>
> And thanks to the analysis at
> "http://www.utasker.com/forum/index.php?topic9.0". This post hinted at an
> unexpected correlation between the updating of TxConsumeIndex and the interrupt
> bit.
>
> Regards,
> Thiadmer Riemersma
>
(specifically, I am using an LPC2468).
I have 7 descriptors for reception and 3 descriptors for transmission. All frames are 1536 bytes long .
I tried the work-around which Thiadmer gived,in the transmit descriptor's controlword, set the interrupt bit (bit 31, in examples from NXP, this bit is definedin a macro called TCTRL_INT or EMAC_TCTRL_INT),
but no use.The tranmission stalls issue still happened after transmit about 4~6 thosand packets.
I have been faced this problem for two month already.
Does anyone have another work-around?
Please help me!!
Thanks a lot.
poki
--- In l..., Norman Felder wrote:
>
> Hi Thiadmer,
>
> Thank you for a very well-written post. This is exactly the kind of information
> that makes a forum like this valuable.
>
> Best regards,
> Norman
>
> ________________________________
> From: compuphase2
> To: l...
> Sent: Wed, September 22, 2010 3:14:31 AM
> Subject: [lpc2000] Re: LPC23xx Ethernet transmission stalls
>
>
> Hello everyone,
>
> Would you believe that I actually tried to search the message forums before
> posting my message. It was only after I sent it that I thought of using the word
> "stall" instead of "block" and search again. Low and behold: this problem was
> reported earlier: see messages #34477 and #34487.
>
> Summarizing the three messages: the problem occurs when the transmit queue fills
> up while TxConsumeIndex = 2 (so TxProduceIndex is 1, in this case). The effect
> is that the transmit queue stalls, and will not resume unless the transmit logic
> is reset. This is less likely to occur with a large transmit queue, and less
> likely when transmitting packets at a slow pace.
>
> Fortunately, there is a simple work-around: in the transmit descriptor's control
> word, set the interrupt bit (bit 31, in examples from NXP, this bit is defined
> in a macro called TCTRL_INT or EMAC_TCTRL_INT). You do not have to handle the
> interrupt, or do anything else. Just setting the bit avoids the problem.
>
> Acknowledgements:
> Thanks to Sven Dreichbach (message #34487) for his precise description of the
> symptoms, convincing me that this is an LPC23xx errata (rather than a
> programming error). Thanks to Sven Dreichbach and Jorge Polar (message #34477)
> for the observation that the problem only occurred when sending out packets
> quickly (something that was true in my case as well, but which I had not paid
> attention to).
>
> And thanks to the analysis at
> "http://www.utasker.com/forum/index.php?topic9.0". This post hinted at an
> unexpected correlation between the updating of TxConsumeIndex and the interrupt
> bit.
>
> Regards,
> Thiadmer Riemersma
>
