USART not receiving correct characters

[HakBot]

I am using a pic18f4550 to transmit data over a wi.232 wireless module from Radiotronix. I have successfully been able to send data but it seems that the later revisions of the pic18f4550 chip do not work correctly with the module.

My problem is that when using the latest A5 revisions of the chips characters sent over the module are not received correctly. Sending a '#' results in a 'n' on the receiving end. Earlier revision chips do not experience this issue. However when putting the chips in loopback mode the transmission is fine and characters are read in correctly. The modules are cmos compatible so I do not think the levels are the problem.

Im running at 9600baud, here is my code which does work:

// configure USART
OpenUSART( USART_TX_INT_OFF &
USART_RX_INT_OFF &
USART_ASYNCH_MODE &
USART_EIGHT_BIT &
USART_CONT_RX &
USART_BRGH_LOW,
77
);

//48000000/(64 * 9600)) -1 = 48000000/614400 = 78 - 1 = 77
//77 = 9600bps

baudUSART( BAUD_IDLE_CLK_HIGH &
BAUD_8_BIT_RATE &
BAUD_WAKEUP_OFF &
BAUD_AUTO_OFF
);


The newer chips do not have any errata docs associated with them. Does anyone have any ideas what my problem could be? Microchip and Radiotronix are not helping me because the chip passes a loopback and the modules work correctly by themselves.

 

[Sceadwian]

Sounds like a baud rate mismatch, perhaps a timeing issue or clock rate difference on the older chip. Send a solid constant stream of "U" 's This will give you a 'clock' on the UART out line that will allow you to determine the actual baud rate it's transmitting at. You can view this on a scope or logic analyzer.

Something is definitly affecting the clock rate, or the same data would be transimited.

 

[Pommie]

I had a problem very similar to this recently. I had a 16F887 with an internal oscillator that ran at 5.3MHz when 8MHz was selected. I wasted a few hours on that problem as I only ever think that hardware is wrong as a last resort. Had I put the above chip in loopback then it would have worked perfectly.

Mike.

 

[HakBot]

Sceadwian,

The funny thing is I tried transmitting the 'U' as you suggested and it works fine!

I will be able to put this on a scope tonight but I am not really sure what to look for.

Do I need some type of interface logic to bump the 5v to 3.3v that the wi.232 module is running on?

 

[bananasiong]

The funny thing is I tried transmitting the 'U' as you suggested and it works fine!

Hi,

Because U is 01010101
**broken link removed**

 

[Oznog]

Are you running on the internal oscillator? Internal osc can be difficult to get the required accuracy. Also in some parts it will start on internal osc and if the primary oscillator won't start properly then it will keep running the internal
osc.

Are you trying to SLEEP between reception? This causes problems with the UART, if the clock oscillator turns off then there's no clock source for the baud clock and it takes too long to start up the osc too to correctly receive at least the first character.

 

[gramo]

If you are using the internal OSC then theres your problem right there. That and keep in mind that it is good practice to throw a 0.1uF and 1uF on the supply to filter spikes and sudden load changes.

I have found in the past that the 0.1uF Tantalum Cap helps improve stability and accuracy by a fair amount

 

[gramo]

The internal OSC is far to inaccurate to be used with highish speed UART

 

[HakBot]

Im using an external 20MHz crystal. With my config bits set (https://i140.photobucket.com/albums/r29/HakBot/cap.jpg) this gives me a 48MHz fosc. I only experience these issues though with the A5 die chips though. Placing an A3 in my circuit yields great results.

Last night I hooked up a TTL->RS232 shifter and I get the same results as the wireless module so this tells me it is really not the module. Radiotronix also stated that nothing is needed in between the mcu's Tx output and the Wi.232 input.

 

[gramo]

Try disabling PLL and reconfigure the program to run @ 20Mhz. PLL has also been known to introduce problems with timing sensitive applications such as UART

 

[HakBot]

gramo,

I disabled PLL. Results from that are the same.

 

[ericgibbs]

hi HakBot,
Have you tried a 'direct' cable link from the PIC UART and a PC?
ie; without the wi module.

This should eliminate/confirm timing problems.


hi gramo,
Long time no see.

 

[HakBot]

eric,

Yes, but I had a ttl shifter in there. The results are the same as the wi module. IE: sending a '#' will result in an 'n' and other unexpected chars. Sending a 'U' again works fine.

 

[HakBot]

I previously thought that there was no pattern to the characters received on the terminal but Ive checked into this further and there does seem to be a pattern. It seems that most of the characters are off by 4 and inverted?

sent from A5 silicon chip read in terminal

putcUSART(1); //xFD
putcUSART(2); //xF6
putcUSART(3); //xF2
putcUSART(4); //xEE
putcUSART(5); //xEA
putcUSART(6); //xE6
putcUSART(7); //xE2
putcUSART(8); //xDE
putcUSART(9); //xDA
putcUSART(10); //xD6
putcUSART(11); //xD2
putcUSART(12); //xCE
putcUSART(13); //xCA
putcUSART(14); //xC6
putcUSART(15); //xC2
putcUSART(16); //xBE
putcUSART(17); //xBA
putcUSART(18); //xB6
putcUSART(19); //xB2
putcUSART(20); //xAE
putcUSART(21); //xD5
putcUSART(22); //xA6
putcUSART(23); //xA2
putcUSART(24); //x9E
putcUSART(25); //x9A
putcUSART(26); //x96
putcUSART(27); //x92
putcUSART(28); //x8E
putcUSART(29); //x8A
putcUSART(30); //x86

 

[gramo]

hi gramo,
Long time no see.

G'day Gibbsy! Yeah it's been sometime since I have been on these forums. I have been overwhelmed with other tasks over the last 3 or 4 months, but slowly getting back in touch with my 'digital' side

Back on topic Personally, I have not had any issues with 18F2550 (the 28 pin version of the 18F4550), and use them and UART extensively.

I'm out of idea's I'm afraid. Perhaps the chip has been internally damaged via static... My last couple of thoughts would be;

- Are all Vdd and Vcc pins (2 of each) connected to their respective supplies?
- Do you have the 0.1uF tantalum capacitor mounted as close as possible between a Vdd and Vcc on the PIC?
- Is your Crystal correctly loaded (what value caps are you using with your crystal?)

 

[Nigel Goodwin]

The internal OSC is far to inaccurate to be used with highish speed UART

The internal oscillator is perfectly fine at 9600 baud, and actually well above that - however, for absolute reliability I always stick to 9600 baud - which is usually more than fast enough anyway.

 

[gramo]

The internal oscillator is perfectly fine at 9600 baud, and actually well above that - however, for absolute reliability I always stick to 9600 baud - which is usually more than fast enough anyway.

I should have rephrased that - the combination of the internal OSC and PLL enabled has been known to make UART unreliable

 

[HakBot]

Its not static unless all my 18 chips are bad.


- Are all Vdd and Vcc pins (2 of each) connected to their respective supplies? yes

- Do you have the 0.1uF tantalum capacitor mounted as close as possible between a Vdd and Vcc on the PIC?
I do have one but its not as close as possible, it is less than 1" away on my board. However this works fine with an A3 chip.

- Is your Crystal correctly loaded (what value caps are you using with your crystal?)
15pF

 

[gramo]

In that case, I guess you have found a piece of information that should be in the ERRATA for the A5 wafer of the18F4550

Try contact microchip about it, and see what their response is

Luckily enough you had other chips to try this with and isolate the problem, I salute you for your perseverance!

 

[HakBot]

In that case, I guess you have found a piece of information that should be in the ERRATA for the A5 wafer of the18F4550

I really hope that is the case because I'm about to start pulling my hair out.

I have been in contact with Microchip and still waiting for their conclusion. I'll post here if I find anything out.