Hi,
which PIC18F4550 silicon version are you using? It could be affected
by the infamous EUSART bug as described here:
http://www.ucapps.de/mbhp_usb_pic.html
The bug has been fixed in rev5
Best Regards, Thorsten.
Am 23.02.2009 um 19:16 schrieb Kustaa Nyholm:
> Hi
>
> I've managed to prune down my code to single/simple one filer that
> reproduces the problem.
>
> I'd welcome any suggestions, including what list is the best list to
> discuss this sort of problem.
>
>
> To re-iterate my problem. I send four bytes ( 4 * 0x55) and receive
> from my Mac, with Java
> as follows:
>
> int cnt=0;
> while (true) {
> cnt++;
> m_OutputStream.write(0x55);
> m_OutputStream.write(0x55);
> m_OutputStream.write(0x55);
> m_OutputStream.write(0x55);
> for (int i=0; i<4; ++i) {
> int
> ch=m_InputStream.read();
> if (ch>=0 && ch!=0x55)
>
> System.out.printf("%d %02X\n",cnt, ch);
> }
> Thread.sleep(50);
> }
>
> So it expects that the 55's are echoed back:
>
> The code on the PIC is below. What it does it received characters
> using interrupt
> and echoes them back. If the character received is not 0x55 it
> toggles on output pin,
> which I'm monitoring with oscilloscope, as well as the data sent by
> my Mac.
>
> Running this code generates a lot of toggles on the output pin and
> on the
> Mac console I see errors too. If I add inter character delays on the
> Mac side
> or remove the sending of echos from the PIC code the errors go away.
> Baudrate has no effect.
>
> So I'm rather baffled, what am I missing?
>
> br Kusti
>
> Here is the PIC code:
>
> #include <stdio.h>
> #include "usart.h"
> #include "pic18fregs.h"
>
> code char at 0x300000 CONFIG1L = 0x20; // USBDIV=1, CPUDIV=00,
> PLLDIV = 000
> code char at 0x300001 CONFIG1H = 0x0E; // IESO=0, FCMEN=0, FOSC = 1110
> code char at 0x300002 CONFIG2L = 0x20; // Brown out off, PWRT On
> code char at 0x300003 CONFIG2H = 0x00; // WDT off
> code char at 0x300004 CONFIG3L = 0xff; // Unused configuration bits
> code char at 0x300005 CONFIG3H = 0x81; // Yes MCLR, PORTB digital,
> CCP2 - RC1
> code char at 0x300006 CONFIG4L = 0x80; // ICD off, ext off, LVP off,
> stk ovr off
> code char at 0x300007 CONFIG4H = 0xff; // Unused configuration bits
> code char at 0x300008 CONFIG5L = 0xff; // No code read protection
> code char at 0x300009 CONFIG5H = 0xff; // No data/boot read protection
> code char at 0x30000A CONFIG6L = 0xff; // No code write protection
> code char at 0x30000B CONFIG6H = 0xff; // No data/boot/table
> protection
> code char at 0x30000C CONFIG7L = 0xff; // No table read protection
> code char at 0x30000D CONFIG7H = 0xff; // No boot table protection
>
> #define LED_PIN PORTBbits.RB4
> #define LED_TRIS TRISBbits.TRISB4
>
> #define CRITICAL(CODE) do { \
> static unsigned char __sdcc_iflags; \
> __sdcc_iflags = (INTCON & 0xC0); \
> INTCON &= ~0xC0; \
> do { CODE; } while (0); \
> INTCON |= __sdcc_iflags; \
> } while(0)
>
> void stdio_init() {
> usart_open(USART_TX_INT_OFF & //
> USART_RX_INT_ON & //
> USART_BRGH_LOW & //
> USART_ASYNCH_MODE & //
> USART_EIGHT_BIT, //
> 77 // = SPBRG, 9600 baud @ 48 MHz CPU clock
> );
> stdout = STREAM_USART;
> }
>
> #pragma nooverlay
>
> volatile unsigned char flag = 0;
>
> void usartirq() interrupt 1
> {
> if (usart_drdy()) {
> unsigned char t;
> flag = usart_getc();
> if (flag != 0x55) {
> if (LED_PIN==0)
> LED_PIN=1;
> else
> LED_PIN = 0;
> }
> }
> }
>
> void main() {
> int i;
> OSCCON = 0x70;
>
> LED_TRIS = 0;
>
> INTCON = 0;
>
> INTCONbits.GIE = 1; // Enable all interrupts.
>
> INTCONbits.PEIE = 1; // Enable peripheral interrupts.
>
> stdio_init();
>
> while (1) {
> unsigned char t;
> CRITICAL (t=flag; flag=0);
> if (t)
> usart_putc(t);
> }
>
> }
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> ________________________________________
> From: Kustaa Nyholm [[email protected]]
> Sent: Sunday, February 22, 2009 9:28 PM
> To: [email protected]
> Subject: [Sdcc-user] PIC18F4550 USART problems
>
> Hi,
>
> I'm having problems with PIC18F4550 USART. I'm using the usart.h
> routines, with interrupts enabled for receiving.
>
> I've got a PC that sends group of three bytes (0x55) through a
> serial port at 9600 baud with no pause between bytes and 100 msec
> between groups.
>
> I have an *low* priority interrupt in the PIC that receives bytes
> from the USART and toggles on output if the byte received is not
> 0x55. No other interrupts are running/enabled. I'm observing the
> output with an oscilloscope. The output never toggles, unless I
> deliberately send wrong characters. As expected.
>
> This works at different baudrates and with different delays between
> chars and groups. As expected.
>
> If I enable my main program loop the problems start. The main loop
> just checks if a character is received and sends out a char through
> the USART. Sending is not interrupt driven.
>
> Observing the output pin and the PIC USART RX pin I see consistently
> that after reception of two character (from PC to PIC) the output
> sometimes toggles. Sometimes it also toggles after the third char.
> This does not happen all the time but intermittently like once or
> twice a second. It never toggles after the first character in the
> group. So the problem happens at about the same time the first
> character that PIC main program sends completes.
>
> If I add a 1 ms (about one char time) between chars sent from the
> PC , the problem mostly, but not totally, goes away. If I add 5 ms
> between chars the problem disappears.
>
> Changing my receive interrupt to toggle every time a character is
> sent I see that sometimes interrupts are missing.
>
> I've googled a bit and looked the chip errata but not found anything
> special, USART and interrupts in PIC seem rather straightforward.
>
> I'll try to come up with a very small self contained test case, but
> meanwhile I'd like to know if there are know issues or things I
> should/could check.
>
> br Kusti
>
>
> ------------------------------------------------------------------------------
> Open Source Business Conference (OSBC), March 24-25, 2009, San
> Francisco, CA
> -OSBC tackles the biggest issue in open source: Open Sourcing the
> Enterprise
> -Strategies to boost innovation and cut costs with open source
> participation
> -Receive a $600 discount off the registration fee with the source
> code: SFAD
> http://p.sf.net/sfu/XcvMzF8H
> _______________________________________________
> Sdcc-user mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/sdcc-user
>
> ------------------------------------------------------------------------------
> Open Source Business Conference (OSBC), March 24-25, 2009, San
> Francisco, CA
> -OSBC tackles the biggest issue in open source: Open Sourcing the
> Enterprise
> -Strategies to boost innovation and cut costs with open source
> participation
> -Receive a $600 discount off the registration fee with the source
> code: SFAD
> http://p.sf.net/sfu/XcvMzF8H
> _______________________________________________
> Sdcc-user mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/sdcc-user
------------------------------------------------------------------------------
Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA
-OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise
-Strategies to boost innovation and cut costs with open source participation
-Receive a $600 discount off the registration fee with the source code: SFAD
http://p.sf.net/sfu/XcvMzF8H
_______________________________________________
Sdcc-user mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/sdcc-user
