PIC18 USART stops working + OERR (overrun error)

[Leo]

Hi all,
here is an add-on to the USART discussions. I hope it helps since I just kept baging my head on the wall going nuts with this:

An ISR services the #int_rda. It is pretty small and stores only the incoming character in a buffer - nothing more. All of a sudden the ISR quits working. The next thing I see is an overrun error (OERR in RCSTA) and no serial interrupt (RCIE in PIE). The baud rate has not influence.

I know all postings regarding GIE, switch- statements and table reads etc., but I got down to this: write_eeprom on PIC18

The write_eeprom(a,b)- statements of CCS (3.152) do:
-load EECONx,.. registers,
-disable GIE
-write to eeprom
-WAITING FOR WRITE BEEING FINISHED(*)
-ENABLING GIE (*)

during the last to statements it MAY happen, that the RCREG changes its value, although NO bit is received from the serial port! NO INTERRUPT is being generated by the PIC ITSELF anymore.

A work-around seems to be using this code (PIC18FXX20) insted of write_eeprom:



#byte INTCON = 0xFF2
void leo_write_eeprom(WORD adr, BYTE b) {

BYTE adr_lo, adr_hi, copy_INTCON;

adr_hi = adr >> 8;
adr_lo = adr;

#asm
MOVFF adr_hi, 0xFAA // EEADRH
MOVFF adr_lo, 0xFA9 // EEADR
MOVFF b, 0xFA8 // EEDATA
BCF 0xFA6.7 // EEC0N1.7
BSF 0xFA6.2 // EECON1.2
#endasm
copy_INTCON = INTCON; // save INTCON
#asm
BCF 0xFF2.7 // GIE in INTCON
MOVLW 0x55
MOVWF 0xFA7 // EECON2
MOVLW 0xAA
MOVWF 0xFA7 // EECON2
BSF 0xFA6.1 // EECON1.1
#endasm
INTCON = copy_INTCON; // restore INTCON
#asm
CheckReg:
BTFSC 0xFA6.1 // EECON1.1
GOTO CheckReg
NOP
BCF 0xFA6.2 // EECON1.2
#endasm
}

The difference between CCS's and this snippet is that I enable the GIE BEFORE I wait for the slow EEPROM to complete writing. Of course I can't use (leo_)write_eeprom in any ISP any more ,but I don't intend to do so.

Additionally CCS's write_eeprom uses the CFGS- bit (EECON1,CFGS), but why? Microchip says not associated with data eeprom mem. Any clue?

Has anybody experiences with similar problems? Or if you try this code, please post a short note if it worked fine with you. Any comments are greately appreciated.

Best wishes
___________________________
This message was ported from CCS's old forum
Original Post ID: 13889

[Neutone]

:=Hi all,
:=here is an add-on to the USART discussions. I hope it helps since I just kept baging my head on the wall going nuts with this:
:=
:=An ISR services the #int_rda. It is pretty small and stores only the incoming character in a buffer - nothing more. All of a sudden the ISR quits working. The next thing I see is an overrun error (OERR in RCSTA) and no serial interrupt (RCIE in PIE). The baud rate has not influence.
:=
:=I know all postings regarding GIE, switch- statements and table reads etc., but I got down to this: write_eeprom on PIC18
:=
:=The write_eeprom(a,b)- statements of CCS (3.152) do:
:=-load EECONx,.. registers,
:=-disable GIE
:=-write to eeprom
:=-WAITING FOR WRITE BEEING FINISHED(*)
:=-ENABLING GIE (*)
:=
:=during the last to statements it MAY happen, that the RCREG changes its value, although NO bit is received from the serial port! NO INTERRUPT is being generated by the PIC ITSELF anymore.
:=
:=A work-around seems to be using this code (PIC18FXX20) insted of write_eeprom:
:=
:=
:=
:=#byte INTCON = 0xFF2
:=void leo_write_eeprom(WORD adr, BYTE b) {
:=
:=BYTE adr_lo, adr_hi, copy_INTCON;
:=
:= adr_hi = adr >> 8;
:= adr_lo = adr;
:=
:= #asm
:= MOVFF adr_hi, 0xFAA // EEADRH
:= MOVFF adr_lo, 0xFA9 // EEADR
:= MOVFF b, 0xFA8 // EEDATA
:= BCF 0xFA6.7 // EEC0N1.7
:= BSF 0xFA6.2 // EECON1.2
:= #endasm
:= copy_INTCON = INTCON; // save INTCON
:= #asm
:= BCF 0xFF2.7 // GIE in INTCON
:= MOVLW 0x55
:= MOVWF 0xFA7 // EECON2
:= MOVLW 0xAA
:= MOVWF 0xFA7 // EECON2
:= BSF 0xFA6.1 // EECON1.1
:= #endasm
:= INTCON = copy_INTCON; // restore INTCON
:= #asm
:= CheckReg:
:= BTFSC 0xFA6.1 // EECON1.1
:= GOTO CheckReg
:= NOP
:= BCF 0xFA6.2 // EECON1.2
:= #endasm
:=}
:=
:=The difference between CCS's and this snippet is that I enable the GIE BEFORE I wait for the slow EEPROM to complete writing. Of course I can't use (leo_)write_eeprom in any ISP any more ,but I don't intend to do so.
:=
:=Additionally CCS's write_eeprom uses the CFGS- bit (EECON1,CFGS), but why? Microchip says not associated with data eeprom mem. Any clue?
:=
:=Has anybody experiences with similar problems? Or if you try this code, please post a short note if it worked fine with you. Any comments are greately appreciated.
:=
:=Best wishes

Microchip has published some errata on theis topic. Writing to internal EEPROM effects the way interupts need to be used. You have to work around that bug in silicon.
___________________________
This message was ported from CCS's old forum
Original Post ID: 13891

[Ron]

IMHO the latest CSS versions automatically do the work arounds for us.

3.125 Compiler work-arounds added for the latest PIC18 errata

Regards,
Ron


:=:=Hi all,
:=:=here is an add-on to the USART discussions. I hope it helps since I just kept baging my head on the wall going nuts with this:
:=:=
:=:=An ISR services the #int_rda. It is pretty small and stores only the incoming character in a buffer - nothing more. All of a sudden the ISR quits working. The next thing I see is an overrun error (OERR in RCSTA) and no serial interrupt (RCIE in PIE). The baud rate has not influence.
:=:=
:=:=I know all postings regarding GIE, switch- statements and table reads etc., but I got down to this: write_eeprom on PIC18
:=:=
:=:=The write_eeprom(a,b)- statements of CCS (3.152) do:
:=:=-load EECONx,.. registers,
:=:=-disable GIE
:=:=-write to eeprom
:=:=-WAITING FOR WRITE BEEING FINISHED(*)
:=:=-ENABLING GIE (*)
:=:=
:=:=during the last to statements it MAY happen, that the RCREG changes its value, although NO bit is received from the serial port! NO INTERRUPT is being generated by the PIC ITSELF anymore.
:=:=
:=:=A work-around seems to be using this code (PIC18FXX20) insted of write_eeprom:
:=:=
:=:=
:=:=
:=:=#byte INTCON = 0xFF2
:=:=void leo_write_eeprom(WORD adr, BYTE b) {
:=:=
:=:=BYTE adr_lo, adr_hi, copy_INTCON;
:=:=
:=:= adr_hi = adr >> 8;
:=:= adr_lo = adr;
:=:=
:=:= #asm
:=:= MOVFF adr_hi, 0xFAA // EEADRH
:=:= MOVFF adr_lo, 0xFA9 // EEADR
:=:= MOVFF b, 0xFA8 // EEDATA
:=:= BCF 0xFA6.7 // EEC0N1.7
:=:= BSF 0xFA6.2 // EECON1.2
:=:= #endasm
:=:= copy_INTCON = INTCON; // save INTCON
:=:= #asm
:=:= BCF 0xFF2.7 // GIE in INTCON
:=:= MOVLW 0x55
:=:= MOVWF 0xFA7 // EECON2
:=:= MOVLW 0xAA
:=:= MOVWF 0xFA7 // EECON2
:=:= BSF 0xFA6.1 // EECON1.1
:=:= #endasm
:=:= INTCON = copy_INTCON; // restore INTCON
:=:= #asm
:=:= CheckReg:
:=:= BTFSC 0xFA6.1 // EECON1.1
:=:= GOTO CheckReg
:=:= NOP
:=:= BCF 0xFA6.2 // EECON1.2
:=:= #endasm
:=:=}
:=:=
:=:=The difference between CCS's and this snippet is that I enable the GIE BEFORE I wait for the slow EEPROM to complete writing. Of course I can't use (leo_)write_eeprom in any ISP any more ,but I don't intend to do so.
:=:=
:=:=Additionally CCS's write_eeprom uses the CFGS- bit (EECON1,CFGS), but why? Microchip says not associated with data eeprom mem. Any clue?
:=:=
:=:=Has anybody experiences with similar problems? Or if you try this code, please post a short note if it worked fine with you. Any comments are greately appreciated.
:=:=
:=:=Best wishes
:=
:=Microchip has published some errata on theis topic. Writing to internal EEPROM effects the way interupts need to be used. You have to work around that bug in silicon.
___________________________
This message was ported from CCS's old forum
Original Post ID: 13899

[Leo]

Thanks for the replys.

I am currently using CCS 3.152 AND experiencing all those problems.

Microchip published errata regaring the 18Fxx39, not the 18Fxx20 series. In the actual errata sheets nothing is said to interrupts, internal memory or table reads.

Best wishes
___________________________
This message was ported from CCS's old forum
Original Post ID: 13903

[Leo]

Thanks for the replys.

I am currently using CCS 3.152 AND experiencing all those problems.

Microchip published errata regaring the 18Fxx39, not the 18Fxx20 series. In the actual errata sheets nothing is said to interrupts, internal memory or table reads.

Best wishes
___________________________
This message was ported from CCS's old forum
Original Post ID: 13904

[R.J.Hamlett]

:=Hi all,
:=here is an add-on to the USART discussions. I hope it helps since I just kept baging my head on the wall going nuts with this:
:=
:=An ISR services the #int_rda. It is pretty small and stores only the incoming character in a buffer - nothing more. All of a sudden the ISR quits working. The next thing I see is an overrun error (OERR in RCSTA) and no serial interrupt (RCIE in PIE). The baud rate has not influence.
:=
:=I know all postings regarding GIE, switch- statements and table reads etc., but I got down to this: write_eeprom on PIC18
:=
:=The write_eeprom(a,b)- statements of CCS (3.152) do:
:=-load EECONx,.. registers,
:=-disable GIE
:=-write to eeprom
:=-WAITING FOR WRITE BEEING FINISHED(*)
:=-ENABLING GIE (*)
:=
:=during the last to statements it MAY happen, that the RCREG changes its value, although NO bit is received from the serial port! NO INTERRUPT is being generated by the PIC ITSELF anymore.
:=
:=A work-around seems to be using this code (PIC18FXX20) insted of write_eeprom:
:=
:=
:=
:=#byte INTCON = 0xFF2
:=void leo_write_eeprom(WORD adr, BYTE b) {
:=
:=BYTE adr_lo, adr_hi, copy_INTCON;
:=
:= adr_hi = adr >> 8;
:= adr_lo = adr;
:=
:= #asm
:= MOVFF adr_hi, 0xFAA // EEADRH
:= MOVFF adr_lo, 0xFA9 // EEADR
:= MOVFF b, 0xFA8 // EEDATA
:= BCF 0xFA6.7 // EEC0N1.7
:= BSF 0xFA6.2 // EECON1.2
:= #endasm
:= copy_INTCON = INTCON; // save INTCON
:= #asm
:= BCF 0xFF2.7 // GIE in INTCON
:= MOVLW 0x55
:= MOVWF 0xFA7 // EECON2
:= MOVLW 0xAA
:= MOVWF 0xFA7 // EECON2
:= BSF 0xFA6.1 // EECON1.1
:= #endasm
:= INTCON = copy_INTCON; // restore INTCON
:= #asm
:= CheckReg:
:= BTFSC 0xFA6.1 // EECON1.1
:= GOTO CheckReg
:= NOP
:= BCF 0xFA6.2 // EECON1.2
:= #endasm
:=}
:=
:=The difference between CCS's and this snippet is that I enable the GIE BEFORE I wait for the slow EEPROM to complete writing. Of course I can't use (leo_)write_eeprom in any ISP any more ,but I don't intend to do so.
:=
:=Additionally CCS's write_eeprom uses the CFGS- bit (EECON1,CFGS), but why? Microchip says not associated with data eeprom mem. Any clue?
:=
:=Has anybody experiences with similar problems? Or if you try this code, please post a short note if it worked fine with you. Any comments are greately appreciated.
:=
:=Best wishes
A series of points.
Firstly, you make no mention of the baud rate involved. This has a significant effect, since it controls the arrival interval of the RS232 interrupt. The write cycle, potentially takes 4mSec.
Your serial code, really should have the handler to deal with the serial error condition. Otherwise anything that can pause interrupt response long enough, will cause this problem.
The interrupts are disabled for the entire write sequence, to avoid any possibility of an interrupted write, once the protection sequence has been sent (otherwise it is possible to corrupt memory). So long as you are aware of this, and keep your interrupt code simple, and do not involve the EEPROM operations, this should not be a problem.
CCS, clear the CFGS bit, since it is required to be zero for this operation, and may have been set elsewhere.
This is the 'key' difference. Their code has to handle the situation that code elsewhere may have set bits, while if you have complete confidence that you are not changing the bits elsewhere, you can ignore this problem. This is the reason for both the CFGS change, and keeping the interrupts disabled.

Best Wishes
___________________________
This message was ported from CCS's old forum
Original Post ID: 13908

[Leo]

I used 9600 and 56400 baud. I tried 18.432 MHz and 19.6608 MHz. With that, my (theoretical) baud error is zero.

I tried the ERRORS- statement in the #use RS232- statement before I moved to my asm- code. But my aim is to avoid error handling, since I want to avoid communication errors. My test- code is pretty simple and nothing disables the GIE for a longer time (checked BCF FF2.7).

The RCSTAT- Registers CHANGES on a EEPROM- write although no sign could be received. (I have sniffer cables adapted).

CFGS: In the PIC18Fxx20 manual (page 80) it seems that CFGS is not involved in data eeprom memory or am I or the manual wrong?

Thanks in advance

Leo
___________________________
This message was ported from CCS's old forum
Original Post ID: 13913

[R.J.Hamlett]

:=I used 9600 and 56400 baud. I tried 18.432 MHz and 19.6608 MHz. With that, my (theoretical) baud error is zero.
:=

In the 9600bps case, the 'byte time', is about 0.8mSec (assuming 8N1). In the 56400 case, the byte time is 0.142mSec. In the 4mSec needed for the write, you could receive 28 characters in the latter case, and about five in the former case. Hence the problem...

:=I tried the ERRORS- statement in the #use RS232- statement before I moved to my asm- code. But my aim is to avoid error handling, since I want to avoid communication errors. My test- code is pretty simple and nothing disables the GIE for a longer time (checked BCF FF2.7).
:=

You can check for errors, and clear them by simply testing the OERR bit, and if it is set, enabling/disabling the UART. This only involves a couple of instructions for the test. Using your code, is also safe _provided you make absolutely sure that nothing will access the EEPROM registers once the security has been bypassed_. This is why CCS take the 'safe' route, and try to ensure that such an access cannot occur.
You have to be very careful, if you operate the code without error checking, since at times, minor changes may result in the interrupts being disabled for a long time (adding some code to any of the interrupt handlers, which is also called externally is the 'classic').
Simple code is:
#BYTE RCSTA1=0xFAB
#BIT OERR=RCSTA1.1
#BIT CREN=RCSTA1.4

if (OERR) {
CREN=0;
CREN=1;
}

The test involves just a bit test, and jump. Enabling then disabling the continuous receive, clears the error. you can then retrieve (potentially) three bytes, but will (obviously) have data loss.

:=The RCSTAT- Registers CHANGES on a EEPROM- write although no sign could be received. (I have sniffer cables adapted).
:=
:=CFGS: In the PIC18Fxx20 manual (page 80) it seems that CFGS is not involved in data eeprom memory or am I or the manual wrong?

No. You are misreading the manual.
It says that this bit has to be low to access the data EEPROM. As I said, the point is that assuming you have not set the bit elsewhere, you can just leave the bit alone, but CCS, have to ensure that it has not been left 'set' by an earlier instruction.

:=Thanks in advance

Best Wishes
___________________________
This message was ported from CCS's old forum
Original Post ID: 13917

[Leo]

Hello PIChelpers!

Thanks a lot for your comments. It really was the slow EEPROM in comparison to the fast USART.

To any PICer who might have this problem ans read this:
Don't USART-ISR-receive and EEPROM- save, but you can
USART-ISR-send and EEPROM- save.

Cheers
___________________________
This message was ported from CCS's old forum
Original Post ID: 13939