Wierd USART0 problem on UC3A0512 custom board

Go To Last Post
4 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi,

I am using the UC3A0512 on my custom board and I am not using the Framework. I have written my own driver with the help of the Framework USART driver.

I need to send some data on the USART0 at 38400 baudrate. The data has to be sent every one second.

Now, the last character of my data packet is not received. A PC is connected to my board, and I use suitable Windows based software to capture this data.

The software is a port from a system based on Microchip dsPIC series and it works perfectly fine. We have migrated from the dsPIC series to the UC3A series. Also, the PC software has been tested thoroughly with the dsPIC board.

So, I think there is some problem in the USART0 initialization or data handling. BTW, I use interrupt mechanism to transmit and receive data on the USART0 port.

Has anyone experience of this sort?

Any comments are appreciated.

Thanks,
-drt

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

If all the other bytes are being sent, it's difficult to think there's a USART problem. After all, it's not like the USART "knows" this is the last byte and decides to do something different with it.

I'd suspect the transmit IRQ handler is simply mis-counting the the transmitted bytes and not stuffing the final byte into the USART.

System info: Win XP, WinAVR 20100110, AVR studio 4.18 build 700, JTAGICE MKII. Atmega 168 & 328, Xmega 192A3.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Thanks for the reply.
Even I think that it would not be the USART problem. But, just wanted to know if there was someone else who faced a similar problem.
I suspected that there would be someone else with similar problems because, as I mentioned in my earlier post that this software is a port from an earlier project based on dsPIC series. It worked perfectly fine there.

Thanks again for the reply.
-drt

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

The problem is solved.
The problem was in my USART code. Apparently, the USART transmit interrupts are slightly different for dsPIC and AVR32. I made a bad assumption :oops:

-drt