PIC18F452 #int_RDA gets clobbered when using Write_EEProm()

[Hans Wedemeyer]

After making a change to some working code it stopped receiving data on the RS-232.

The change involved several lines of code including some calls to Write_EEprom();
As the RS-232 is set to run at 1.25 Mega Baud I focused on that as the reason for lack of reception, after all it is a very high Baud rate, however it is TTL connected to another PIC and the distance is less than 1 inch, and has worked before.

Slowly working backwards and ending up with 9600 Baud it still refused to receive data.

Next step was to remove the other code changes.
I did this step by step until RS-232 data reception started to work.

The offending line of code is a call to Write_EEprom();

Looking at the LST file for other known good code the call to Write_EEprom() looks different.

The first thing I noticed in the code that does not work, is
CLRF FAA

Not knowing what FAA is, I looked it up in the data sheet and it is has no function, and a search produces nothing!

From the data sheet:
FABh RCSTA
FAAh --------
FA9h EEADR

What exaclty is FAA register used for ? Microchip does not mention it in the data sheets I have.

LST listing for calls to :- Write_EEprom(Address, Val )

Works
070E: MOVFF 627,FAA
0712: MOVFF 626,FA9
0716: MOVFF 628,FA8
071A: BCF FA6.6
071C: BCF FA6.7
071E: BSF FA6.2
0720: MOVFF FF2,00
0724: BCF FF2.7
0726: MOVLB F
0728: MOVLW 55
072A: MOVWF FA7
072C: MOVLW AA
072E: MOVWF FA7
0730: BSF FA6.1
0732: BTFSC FA6.1
0734: BRA 0732
0736: BCF FA6.2
0738: MOVF 00,W
073A: IORWF FF2,F
073C: MOVLB 0
073E: RETLW 00

Does not work
0126: CLRF FAA
0128: MOVFF 176,FA9
012C: MOVFF 177,FA8
0130: BCF FA6.6
0132: BCF FA6.7
0134: BSF FA6.2
0136: MOVFF FF2,00
013A: BCF FF2.7
013C: MOVLB F
013E: MOVLW 55
0140: MOVWF FA7
0142: MOVLW AA
0144: MOVWF FA7
0146: BSF FA6.1
0148: BTFSC FA6.1
014A: BRA 0148
014C: BCF FA6.2
014E: MOVF 00,W
0150: IORWF FF2,F
0152: MOVLB 0
0154: RETLW 00

Compiler is PCH 3.212

[Mark]

FAA is the EEADRH register. It is used on those devices with more than 256 bytes of eeprom, like your 6720's

[Guest]

[Mark]

Here is some snippets from Microchips bootloader:

[Guest]

Can't agree with "can't blame them because..."

CCS is supposed to output clean code (#&^#$&^%$&^ spit)

How much trouble would it be...
They already know the chip type from the header file.

Anyway, this does not cure the problem I'm having, just one call to Write_EEprom() kills rs-232 reception. !

A search revealed this is an old problem for PIC16 chips. Some one had a solution for that using asm verson of Write_EEprom().

I also tried an ASM version of Write_EEProm() based upon the MicroChip's PIC18 data sheet ( a little different to the PIC16 version), this did not use the FAA register.

It did not help, same problem one call to Write_EEProm() and RS-232 reception is dead .

[Charlie U]

Hans,

Don't forget that Microchip "strongly recommends" that all interrupts be disabled during the Data EEPROM write cycle. From your code you can see that CCS is doing just that. During the entire time that the code is waiting for the write to complete, interrupts are disabled.

These lines:

0720: MOVFF FF2,00
0724: BCF FF2.7

save the contents of the INTCON reg (FF2) and turn interrupts off (bit 7 is the GIE)

and these lines:

0738: MOVF 00,W
073A: IORWF FF2,F

turn interrupts back on.

The self-timed EEPROM write typically takes 4 ms, which is an eternity for your 1.25 Mbaud data. Also, 4ms is approximately 4 full character times at 9600 baud. So, as a result, even at 9600 baud, you could be trying to receive up to 4 characters over the serial port while the EEPROM write is waiting to complete.

So my guess is that it isn't the code, it's the EEPROM write wait time with interrupts disabled that is affecting your program.

[Gerrit]

Hello Hans,

I think Charlie U is right about disabling interrupts on write cycle.

But what CCS is doing is waiting until the byte is written to enable the
interrupt again.

According Microchip you only need to disable the interrupt when writing
the 55, FF sequence.
You do not need to wait till the byte is written to eeprom (can take from 1 to 10 ms) you can check before the next write cycle if the last byte was written.


advice write your own eeprom_write function that only does what you want and need.


Could you explain at what rate, and how mutch data you need to write to eeprom. Maybe there is a other solution.



regards,

Gerrit

[PCM programmer]

[JerryI]

From Readme file for compiler;

I don't know if it will help.

New directive to prevent WRITE_EEPROM from hanging while
the write takes place:
#device WRITE_EEPROM=ASYNC
If you use this do not write to the EERPOM from both an ISR
and outside an ISR.

[future]

A piece of code from my app.

It will save the entire cfg struct to eeprom. I have another 4 interrupts working with it.

To call it use:

[Guest]

[Guest]

[Guest]