Continue to Site

Welcome to our site!

Electro Tech is an online community (with over 170,000 members) who enjoy talking about and building electronic circuits, projects and gadgets. To participate you need to register. Registration is free. Click here to register now.

  • Welcome to our site! Electro Tech is an online community (with over 170,000 members) who enjoy talking about and building electronic circuits, projects and gadgets. To participate you need to register. Registration is free. Click here to register now.

UART communication between two MCU's

Status
Not open for further replies.

faysal_002299

New Member
Dear all,

I am using dsPIC30F3011 for motor control. As this MCU doesn't support any usb communication, I am using another Atmel MCU (AT90USB82/162) for the USB communication with the host PC. Intercommunication between the 2 MCU's is done by SCI (UART).

The problem is in case of data exchange I am observing some weird things. Say, when I send a sequence of numbers (8 bit) from MCU to PC, the data I am reading from my host is ok for the last 4 bits but for the upper 4 bits it's not matching with the original data. For examle,

Data Supposed to receive: 0x11, 0x22 0x33 0x44 0x55 0x66 0x77 0x88 0x99 0xAA 0xBB 0xCC 0xDD 0xEE 0xFF

Received Data: 0x91 0xA2 0xB3 0x84 0x95 0xA6 0xB7 0xC8 0xD9 0xCA 0xDB 0xEC 0xFD 0xEE 0xFF

[This is happening for all sets of number. That's to say, instead of 0x1 in the upper 4 bit I am always getting 0x9, instead of 0xA in the upper 4 bit I am always getting 0xC no matter what's in the lower 4bit. But in case of 0xE or 0xF in the upper 4bit I am receiving 0xE and 0xF (nothing's wrong here). On the other hand, in case of lower 4bit there is never any problem]

Please tell about all the possible reasons for happening this kind of thing so that I can do the troubleshooting.

waiting for your kind reply. Let me know if you need any further info.

Thanks in advance
Faysal
 
what are you using for your oscillators? having the last bits come up wrong sounds like a frequency mismatch. uarts rely on timing from the start bit so the errors add up over the course of each transmitted byte.

in other words if you have a 10% bit rate mismatch and 8N1 coding for 10 bits per transmitted byte (1 start bit, 8 data bits, no parity, 1 stop bit) you completely lose the last bit.
 
what are you using for your oscillators? having the last bits come up wrong sounds like a frequency mismatch. uarts rely on timing from the start bit so the errors add up over the course of each transmitted byte.

in other words if you have a 10% bit rate mismatch and 8N1 coding for 10 bits per transmitted byte (1 start bit, 8 data bits, no parity, 1 stop bit) you completely lose the last bit.

I am using crystal oscillator. Baud rates for both the MCU are 57600. But the frequency of the crystal oscillators are 50000 and 80000. Is that a problem? I am using no parity.

I have checked the total thing thousand times and I never get anything wrong for the last 4 bits. But for the upper 4 bits it follows the pattern like:

should receive---------actual receive
1------------------------9
2------------------------A or 8
3------------------------B or 9
4------------------------8 or A
5------------------------9 or B
6------------------------A
7------------------------B
8------------------------C
9------------------------D
A------------------------C or E
B------------------------D or F
C------------------------E or C
D------------------------F or D
E------------------------E
F------------------------F

Please help me
 
Last edited:
it really seems like your baud rates are not the same. here we would measure it on the scope, but you probably do not have one... you should double check your uart bit rate configuration, you might have slipped a /2 somewhere.
 
BAUD rate setting is ok

it really seems like your baud rates are not the same. here we would measure it on the scope, but you probably do not have one... you should double check your uart bit rate configuration, you might have slipped a /2 somewhere.

Hi, I have checked the baud rate and UART bit rate configuration. There seems to have no problem. Please suggest me some other possible reasons for happening this.
 
i dont think he wants to as i asked that already. Im sure the issue would have been resolved a while ago if he had posted the code and maybe a schematic.
 
Last edited:
i dont think he wants to as i asked that already. Im sure the issue would have been resolved a while ago if he had posted the code and maybe a schematic.

Unfortunately, many people believe they have discovered something unique and are not willing to share it as it will be stolen and their royalty cheques will vapourise (UK speilling).

Personally, I know that my latest brainwave is so unique that it will make squillions. Unfortunately, I had it two hours ago and I've forgotten it now.:confused: Bugger.

I'm sure I'll remember in the morning.

Mike.
 
code attached!!

Sorry, I was not online for a while. Please don't take it otherwise- actually I thought that- as my code is so messy, it will be annoying for you guys to analyze that. Anyway I have attached it now.

I am just a beginner- I have no way to do something unique :)

Thanks to you all for being so helpful.
 

Attachments

  • test.c
    18.6 KB · Views: 358
Unfortunately, many people believe they have discovered something unique and are not willing to share it as it will be stolen and their royalty cheques will vapourise (UK speilling).

Personally, I know that my latest brainwave is so unique that it will make squillions. Unfortunately, I had it two hours ago and I've forgotten it now.:confused: Bugger.

I'm sure I'll remember in the morning.

Mike.

Yes, I think you are correct on that one. :p:p:p
It is even worse in the 'art-world,' where those who have never studied the history think everything they do is original and worth a fortune.:p

A worthwhile read is T.S. Elliot's "Tradition and the Individual Talent."

Faysal, see what happens when there is no answer back - we start making up stories. :) :D :p
 
Last edited:
I understand that pommie but the thing to remember is if you need help you have to show what you have that needs help on most often to get a good answer. No one asked for full source. Just partial at least so we can see what could be going wrong.
 
I have found that PICs do unexpected things if the UART receiver has overflowed and the overflow bit isn't clear. I didn't see anything in your code that will cause the processor to stall if the outgoing data is being sent too quickly. I don't recall the bit name, but I'd at least put a while buffer not empty loop spinning before loading the uart transmit buffer with a byte. Better yet, have SendData stuff a buffer and enable an interrupt to transmit the data.

Have you confirmed where the data corruption is occuring? Many of the higher end PICs I've used in the recent months have a 4 byte UART buffer so it could maybe handle the 3 SendBytes you have in a row at one point... so long as it is a while before it gets to another SendByte. The corruption may be happening at the Atmel part. I haven't kept up with their stuff recently, but everything of theirs that I've used had only a one byte buffer. You might be having problems there.

Or just get rid of the Atmel part and use a USB<->Serial chip. FTDI and Silicon Labs have some easy to use parts, I think both companies have a single chip solution that requires almost no external parts.
 
Last edited:
Thanks a lot. I have thought about the buffer size. But the problem is, I get the same error when I send data from MCU to PC at a very slow pace like after every 1/2 seconds. In case I use the SendData() function in two consecutive lines, only the first one works and I get nothing in the PC for the second line.

The problem of using Serial>USB converter is if we go for a mass production of our device then it wouldn't be cost effective, where using another MCU will save a lot.

However thank you a lot for reading my messy codes.

Should I use a TX Interrupt for the SendData?
 
Last edited:
Should I use a TX Interrupt for the SendData?

USB<->Serial devices can be purchased relatively cheaply, I don't know what the Atmel USB part costs though. If you're only sending a byte at a time with plenty of time between bytes, I don't know that interrupts would do you much good.

The best favor you can do for yourself right now is to put a scope on the serial lines and measure bit widths and time between bytes. At 57600 baud, the bit width should be 17.4uS.
 
Ressurection from the dead!

This thread is only 3 years old.
 
Status
Not open for further replies.

Latest threads

New Articles From Microcontroller Tips

Back
Top