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

Sat Sep 29 04:13:03 PDT 2007

Hi John.

I'll try it next week.

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 22: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: SV: SV: [Icc-avr] Debug using Jtag

Hi Steven,

I would be even more blunt than that and not enable the TXC interrupt until you have finished with UDRE.

Void UDRE_INT(void)
{
 If (No more Data to send)
 {
  Disable UDRE int.
  Enable TXC int.
 }
 Else
 {
   Put data in buffer
   Clr TXC flag.
 }    
}

All the best for now,
John

At 18:57 28/09/2007, you wrote:

Content-class: urn:content-classes:message
Content-Type: multipart/alternative;
         boundary="----_=_NextPart_001_01C801F9.0473DD52"

;o)

The solution on my problem is like below:

Void UDRE_INT(void)
{
 If (No more Data to send)
 {
  Disable UDRE int.
 }
 Else
 {
  While(DataToSend && BufferEmpty)
  {
   Put data in buffer
  }
  Clr TXC flag.
 }    
}

My first shot was just to clr the TXC flag at once, but then I found that it could actually clr a TXC flag that was needed.

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/> 

________________________________

Fra: icc-avr-bounces at imagecraft.com [ mailto:icc-avr-bounces at imagecraft.com <mailto:icc-avr-bounces at imagecraft.com> ] På vegne af John Baraclough
Sendt: 28. september 2007 18:57
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: SV: [Icc-avr] Debug using Jtag

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

www.ecpower.dk <http://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/>  
_______________________________________________
Icc-avr mailing list
Icc-avr at imagecraft.com
http://dragonsgate.net/mailman/listinfo/icc-avr
_______________________________________________
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/20070929/f25845aa/attachment-0001.html