1

I'm having trouble with a project using a PIC 18F87J50, specifically in my coordination with its 2 USART channels.

There are 2 main problems.

1.) Unable to set target Baud Rate:

I'm using the Open1USART() and Open2USART() functions to initialize the two USART channels I'm using. I want them to both be configured to 14,400 Baud. These functions take 2 arguments. The first is a bit field to configure the USART (async vs sync mode, 8bit vs 9bit, etc.) The second is the SPBRG value which (depending on the system clock rate) configures the USART's baud rate.

I'm calling both like: Open1USART(USART_ASYNCH_MODE & USART_EIGHT_BIT & USART_BRGH_LOW & USART_RX_INT_ON & USART_TX_INT_OFF, 346);

In my setup, 346 as the SPBRG seems to give me 14,400 Baud (confirmed on an O-scope that the width of one bit is about 70us).

The problem is that this only works for USART 2. On USART 1, the same SPBRG value gives me a Baud rate of 57,600. Further, in playing around with the SPBRG value (and looking at the scope timing to see the actual baud rate affect), I saw some interesting things.

The Baud rates decrease as I increase the SPBRG value up from 0. SPBRG of 87 gives me 57,600 baud, 173 -> 28,800... but it resets at about 255. At 255, I have a baud rate of about 19,000. But at 256, I have an incredibly high baud rate (~1,000,000). Then as I move the SPBRG number up further the baud rate slows down further and further, but never lower than that 19,000 baud mark and never all the way down to my needed 14,400.

Ok, so I'm overflowing the SPBRG byte, right? But USART 1 and 2 are configured the exact same way and I'm able to go with SPBRG values > 255 on USART 2. They both have the same BRGH setting (low) and BRG16 setting (high). Also, as per this post (No interrupts being triggered in UART Receive on PIC18F2680), it seems that TRISC6-7 are important bits to set correctly. I have these set as that post suggests (6 low, 7 high).

I can share some code snippets if that would be helpful.

2.) ISR not triggering for each incoming byte:

I have the UART RX interrupts turned on for both USART1 and 2. I'm not talking out on USART1 at the correct baud rate so am not hearing back from my peripheral. But, on USART2 I am talking at 14,400 baud and my peripheral device is replying back appropriately (verified with scope). With the scope I can see all 16 bytes that I expect to receive back and the timing looks great on the wire. However, my RX interrupt for this port is only triggering for the first 2 or 3 bytes. I need to receive 8 bytes in a row to know what the peripheral is replying with... but I never get past 2 or 3.

So the interrupt is triggering, but not for all of the bytes.

I know that I need to keep my ISR pretty short in order not to miss the next incoming byte's interrupt, but even when I strip the ISR down to just its core functionality (removing debug print outs, etc.) I'm still only seeing the first 3 bytes. On the scope, there's no difference I can see between the first 3 bytes and the remaining ones (at least not in bit timing). The value of the first three bytes is always 0xFF (which is expected). The remaining bytes are different values, but that's the only difference I can see and it doesn't really explain why there's no ISR trigger. The above referenced link to the other question certainly seems relevant to this issue as well. But the ISR is triggering, just not all the time.

Any help or insight you could offer would be greatly appreciated and I will double-check with my client to ensure that I can add some further code snippets.

Community
  • 1
  • 1
  • Regarding 2), do you check for overrun, parity and whatever other error flags that the uart supports? – Lundin Jan 14 '13 at 14:14
  • Good question... I'll take another look into the (mostly legacy) code and spec sheet. Do you happen to know how to check these flags? I think I'm mostly just grabbing from the RCREG. That being said, I'm only making it into the ISR for the first 3 bytes. So I wouldn't be able to check these error flags on the remaining bytes (but perhaps something bad is happening on that 3rd byte that I need to see) – Dave Masselink Jan 14 '13 at 17:09
  • I have no experience with PIC but those exist on all UARTS: overrun error (overflow), framing errors (start/stop bits wrong, likely clock related) and parity errors (poor man's checksum). – Lundin Jan 14 '13 at 20:00

0 Answers0