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

[Steven Lose]

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: sl at ecpower.dk <blocked::mailto:bsl 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: sl at ecpower.dk <blocked::mailto:bsl at ecpower.dk> 

www.ecpower.dk <http://www.ecpower.dk/>  

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://dragonsgate.net/pipermail/icc-avr/attachments/20070928/fea33221/attachment.html