Problem with 2 18LF4550 and uart

magestik · Joined: 16 Oct 2008 Posts: 59

Hello,

I am having a big problem using UART, let me explain :

I'm having 2 PIC, one is basicaly getting characters, the other one is sending them.
I posted the full program, which is quite complex, but a few lines are necessary. As you can see below, PIC1 is using fgetc at 9600 bauds.

The PIC2 is basicaly sending 0x08 and 0x0D to PIC1.

Ttelmah · Guest

You have a lot more going on, that you imply....

On PIC2, how critical are the 40uSec sampling times?. You are doing looped access to an array of bits. I'd expect the code for this alone, could be easily taking several uSec....
Then, you walk through a bit array, looking for 9 edges. If you don't see these, this part of the code will never exit, and could loop right through memory.

Then, you have a header loading on PIC1, which suggests is i using a USB bootloader. _This_ will have it's own fuses. Normally, if a bootloader is present, it has to have the fuses set the way it needs, and won't change them. One obvious suggestion, is that this doesn't use the HS fuse, but has the PLL selected. If so, the clock rate on this chip will not be 20MHz, but 48MHz (if the rest of the fuses match what you have on PIC2).

Seriously, throw away the code, and prove where the problem is.
You show exactly what you need as 'test' code, at the top of your post, so use it. Make a simple loop, wait a few milliseconds, send a pair of bytes with an easily recognisable data pattern (0xAA 0x55), and loop. _Time_ the waveform, is the frequency what you expect?. If not, you have a timing problem in PIC2. If it is, start looking at PIC1. Have it simply read bytes as received, and toggle an output line. Does the line toggle 1/960th second after the first falling edge?. If not, then you have a timing problem in PIC1.

Simple rule, before posting, _simplify_.

Best Wishes

magestik · Joined: 16 Oct 2008 Posts: 59

Oh I didn't know using a bootloader will have its own fuses !!!!!!!!!!
I changed clock=20000000 to clock=48000000, everything works now.

Thank you so much, you saved me Very Happy

.
I never read that information anywhere Confused

.

My bootloader is :

Ttelmah · Guest

That is not the bootloader.
That is the code to tell the compiler to leave space _for_ the bootloader.

The bootloader, is another complete program, which executes normally on 'boot' (hence the name), and looks for some 'key' to say that it is to load data from a source into the memory. The 'key', can be an external pin, a particular character, or timing based (all depends on the bootloader involved). When it sees this key, it carries on executing, and loads code. If the key is not seen, it then jumps to your program.

The bootloader, is then a complete program (with fuses), loaded into the chip, which itself then allows you to program the rest of memory (the area where it is not present), without having to use a programmer.

Now the bootloader _must_ know the chip's clock rate, and configuration, or it can't run. If (for instance), the bootloader was written to use 'HS', and you were allowed to reprogram the fuses, and changed them to INT_RC, the bootloader would no longer be able to handle the serial, since the clock had changed...
So, normally the bootloader _won't_ reprogram fuses. You
have to set your main code, to use the same fuses as the bootloader was configured to use. The behaviour is down to the intelligence of the original bootloader. Some will just ignore fuse changes. Some will warn you. Some will allow fuses to change that don't affect the clock. Some will reprogram fuses, and then stop working.....

If you look at 'loader.c' (the CCS example bootloader), you will see, that it only programs data with addresses below 0x300000 (for the 18H chips). 0x300000, is the start of the locations for the configuration data (fuses). So this bootloader, just silently ignores fuse settings in the program it is loading (commonest solution).

Best Wishes