Hi thanks for the tip, I had read it and on the first reading I thought nothing matched my case. On second reading I started to suspect that maybe reading the TXSTA register (which happens inside usart_getc) could trigger the baudrate counter reset bug that was reported for writing TXSTA but removing that access helped none.
Then I noticed that in the morning I did not have this problem any more! Retrying and playing around brought the problem back. So what the heck? Maybe something to do with temperature, it was rather cold night and the workshop was a bit chilly in the morning. But then what do you expect from a silicon bug, could well be related to temperature... but then it stared me right in the face on the oscilloscope: if I looked carefully the first byte sent from Mac to PIC had ever so slightly lover voltage levels for zeros. If I added delay between characters the voltage levels for all bytes very the same and on besides, on closer inspection, zero level was too close to 0.2VDD for my liking. At this point I may have to explain that I've got an opto coupler (4N35) in the serial line and I'm using a FTDI chip based UBS/Serial converter cause Mac have no serial port. Anyway it turned out that the USB/Serial converter uses some sort of charge pump (MAX232A???) to generate +-5 V from the USB +5 V to drive the RS232 lines. This is of course outside spec for RS232 anyway but I knew this so I'll let it pass. But when sending characters back to back the signal levels droop a little bit (the charge pump recovers if there is an inter character delay) and because I had based my opto drive series resistor on the +-12 V drive value the signal transmission was just marginally working at +-5 V. Reducing the series resistor from 4k7 to 2k2 removed all the problems. So, in the end my fault and a hardware fault at that. Just thought I'd let everyone know and not left them wondering if there is something wrong with the PIC. Well, there is , if you read the errata, but in my case it was not any of those issues. br Kusti > From: Thorsten Klose <thorsten.kl...@gmx.de> > Reply-To: <sdcc-user@lists.sourceforge.net> > Date: Mon, 23 Feb 2009 22:17:19 +0200 > To: <sdcc-user@lists.sourceforge.net> > Conversation: [Sdcc-user] PIC18F4550 USART problems - a self contained example > Subject: Re: [Sdcc-user] PIC18F4550 USART problems - a self contained example > > > > 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 [kustaa.nyh...@planmeca.com] >> Sent: Sunday, February 22, 2009 9:28 PM >> To: sdcc-user@lists.sourceforge.net >> 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 >> Sdcc-user@lists.sourceforge.net >> 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 >> Sdcc-user@lists.sourceforge.net >> 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 > Sdcc-user@lists.sourceforge.net > 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 Sdcc-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sdcc-user
