Version 5.049 baud rate issue

[wc6r4]

I recently updated from version 4.068 to 5.049, and I'm having an issue with the same code working in both versions. Whenever I use either compiler, the code compiles, but when I attempt to communicate over RS232 to my PIC18F4553 via TeraTerm using printf statements, version 5.049 seems to be creating the wrong baud rate, as all of my output looks like garbage, but 4.068 has no issue. Anyone have any ideas as to why this might be the case?

Below are the delay and rs232 instantiations I'm using.

[ezflyr]

Hi,

You should post your Fuses for us to take a look at!

In the meantime, try the ol' Flash-an-LED test to see if your PIC is running at the expected speed. I suspect it's not because your Fuses are wrong, with one compiler version caring, and the other not?

We'll see.....!!
_________________
John

If it's worth doing, it's worth doing in real hardware!

[Ttelmah]

Agree wholeheartedly with Ezflyr's comment/question on fuses.

4.068, was a fairly 'borderline' version of V4. It was just about the first reasonably working version. Now V4, in some versions _defaults_ to setting some of the fuses differently to their normal 'erased' state, even without the user specifying a fuse.
V5 compilers default to leaving all fuses unset, unless the user specifies a value.

I's suspect the clock fuses are not setup correctly, and either the CPUDIV ratio is wrong, or the actual oscillator selection is wrong. In the former case the CPU will be running at a division of what is expected, while in the latter, the main oscillator won't be starting, and it'll be dropping 'back' to the emergency internal RC oscillator. In both case the baud will then be wrong.

So, post the fuses.

[wc6r4]

I haven't gotten a chance to see my clock, but here are my fuses:

[Ttelmah]

The obvious one that will cause problems is CPUDIV. Add CPUDIV1.

The V5 compilers leave these bits at '11', which is the erased state, so you will get CPUDIV4.

[wc6r4]