SV: SV: SV: SV: [Icc-avr] Debug using Jtag

[John Baraclough]

Hi Steven,

Well to be fair, once I found what the problem 
was I did take the sledgehammer approach and just 
cleared the TXC flag every time I hit the UDRE 
interrupt. As the project target date was fairly 
close, I never analysed the the problem as you 
have done. It looks as though your problem and 
mine are similar in that the UDRE interrupt 
latency allows the buffer to empty before the new 
write and enables the TXC flag to be set.

Maybe the data sheet is correct after all and I 
was just too hasty in my conclusions at the time. 
:-[ However the project got delivered on target 
and the customer was happy, so I never bothered to revisit it.

All the best for now,
John


At 16:23 28/09/2007, you wrote:
>Content-class: urn:content-classes:message
>Content-Type: multipart/alternative;
>         boundary="----_=_NextPart_001_01C801E3.978301C5"
>
>Hi John.
>
>I’ve had a counter in the TXC routine, cleared 
>when Send routine was called and sampled for lcd 
>when TXC was terminating the transmission.
>The counter showed in my case 1 or 2 for packet 
>size of 13 – 22 bytes. So by that I assume that 
>it gets called an extra time when tx buffer was 
>running empty before UDRE was able to refill the 2 byte Tx buffer.
>Otherwise it should have counted 1 up for each byte, correct?
>
>I don’t know with the Mega32, but I will have a 
>look at my SW for them later and make the counter test again.
>
>Med venlig hilsen / Best regards / mit freundlichen Grüßen
>
>EC POWER A/S
>
>Steven Lose
>
>Software Ingeniør
>
>Tlf.: +45 87434100
>
>Direkte tlf. +45 58286608
>
>Email: <blocked::mailto:bsl at ecpower.dk>sl at ecpower.dk
>
>www.ecpower.dk
>
>----------
>Fra: icc-avr-bounces at imagecraft.com 
>[mailto:icc-avr-bounces at imagecraft.com] På vegne af John Baraclough
>Sendt: 28. september 2007 16:59
>Til: Discussion list for ICCAVR and ICCtiny 
>Users. You do NOT need tosubscribe to icc-announce if you are a member of this.
>Emne: Re: SV: SV: SV: [Icc-avr] Debug using Jtag
>
>I think the data sheet is incorrect (certainly 
>for mega32 and by implication for all other mega 
>parts as well) as I found a similar problem when 
>doing a Bluetooth interface last year. A 
>slightly different scenario where the USART 
>receiver has to be selectively disabled so that 
>commands don't get continuously looped like 
>perpetual motion. It took quite a while to find that one.
>
>All the best for now,
>John
>
>
>At 14:37 28/09/2007, you wrote:
>
>Content-class: urn:content-classes:message
>Content-Type: multipart/alternative;
>         boundary="----_=_NextPart_001_01C801D4.AEA2D19E"
>
>Hi John.
>
>Thanks a lot for offering your help.
>I try a bit more before I start crying in your mailbox.
>
>That’s how my mail started and I wrote a whole 
>lot more before the 10cent hit me
 hard. Still hurts.
>
>This product have something all the other 
>products using this uart code don’t have.
>A  heavily loaded cpu, and as I already have 
>testet, the TXC is called before tx is complete.
>Meaning that the TXC flag is just standing there 
>waiting for UDRE to fill the last byte in, 
>leaving the data index pointer on the NrOfBytesToSend value
>And TXC is executed a uSec later.
>
>After 5 days of debug, it’s getting difficult to 
>sort out the results of all the tests I’ve made.
>
>As you said, clear the flag for every UDRE interrupt. Obvious.
>Where shall I send the T-shirt?
>
>Then it’s going to be a nice weekend anyway, thanks a lot.
>Have a very nice weekend, and to all others too.
>
>By the way, datasheet says:
>The Transmit Complete (TXC) flag bit is set one 
>when the entire frame in the Transmit
>Shift Register has been shifted out and there 
>are no new data currently present in the
>transmit buffer.
>
>
>
>
>Med venlig hilsen / Best regards / mit freundlichen Grüßen
>
>EC POWER A/S
>
>Steven Lose
>
>Software Ingeniør
>
>Tlf.: +45 87434100
>
>Direkte tlf. +45 58286608
>
>Email: <blocked::mailto:bsl at ecpower.dk>sl at ecpower.dk
>
>www.ecpower.dk
>_______________________________________________
>Icc-avr mailing list
>Icc-avr at imagecraft.com
>http://dragonsgate.net/mailman/listinfo/icc-avr
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://dragonsgate.net/pipermail/icc-avr/attachments/20070928/e8d0d21e/attachment.html