I2c Force_hw problem

[Remko]

Hello,

I am using I2C and RS232 communication. When the RS232 Comunication gets very busy, the I2C communication begins to fail. According to microchip this should not happen because I2C is hardware. The compiler makes software routines unless you specify FORCE_HW. After putting it in, my I2C does not work at all. After cleaning the complete project and only put in the I2C and show it on display, the problem still exist.
When I measure with the scope on the clk pin, it shows me a very nasty signal with FORCE_HW on.
Can anyone tell me how I can get the I2C to work with FORCE_HW.

PIC18F452 @ 20MHz
24LC256
V3.249

Best regards,

Remko

[Ttelmah]

What pull up resistors are you using?. The hardware will default to operating significantly quicker than the software I2C, requiring lower value pull-ups if there is significant capacitance on the line.

Best Wishes

[Remko]

Tank you for you reply,

The resistors are 1k. When I measure with my scope I can see the speed is much to high, so that one is right (with hardware I2C, not with software I2c). After putting in slow, I can see the CLK go from 0V to 5V so that one must be right. The signal is not a nice clock signal...
But, I have it working now. I deleted the line #use I2C(...) in the 24LC256.C file and put it in my HAL file right behind the #fuses, #use delay and #use RS232. Now the hardware I2C works fine but my problem is not solved.

After debugging I found out that the variable address (a long) is changed after busy communication throuht RS232 on interruptbase. Also other variables are changed after busy RS232 communication. I have made my own ISR. The start of the ISR is:

#INT_GLOBAL
void Int_serv(void)
{
char chartemp;
#asm
MOVLB 0 // to get proc in bank 0
#endasm

if (INT0IF && INT0IE) {
...
...
INT0IF = 0;
}
...
...
...
...


while (RCIF && RCIE)
{
RCIFShadow = 1;
chartemp = getc();
if (chartemp == ':') // 0x3A
rs232_i = 0;// PutRs232_i ; PutRs232_i&=0x07;
if ((chartemp == '#')||(chartemp == 'A')){
string[PutRs232_i][rs232_i] = chartemp;
if (rs232_i < 17) rs232_i ;
chartemp = '\r';}

if (chartemp != 0x0A) // Line Feed
{
string[PutRs232_i][rs232_i] = chartemp;
if (rs232_i < 17) rs232_i ;
if (chartemp == '\r') {
rs232_i = 0;
PutRs232_i ;
PutRs232_i &= 0x07;
} // end if (chartemp == '\r') {
} // end if (chartemp != 0x0A)
} // end if (RCIF && RCIE)

#asm
RETFIE 1 // Return from interrupt fast
#endasm
}

string is:
char string[8][18];

Is there something wrong with the context saving for example, or something else?

[Ttelmah]

Your interrupt code will bu**er things up.
You are using arrays, which inherently means access to the table registers, and are not saving/restoring these in your handler.
When you write an int_global, it is _your_ responsibility to save _every register_ that is used in the handler. You need to go through the listing file, and work out what your code uses. Also, Assuming the PutRS232i, is the actual hardware register, there is no sign that I can see, of you handling a possible overrun condition, which will lock the UART.

Best Wishes

[ckielstra]

Please use the 'Code' button when posting code, this helps to retain the formatting.

[Remko]

Hello,

The code is actually:

[Ttelmah]

No. It is the table handling that is likely to be killing you.
The probables are:
Table pointers.
FSR registers.
Scratch memory.

Best Wishes

[Remko]

All right, I am beginning to understand. Those things the compiler does which I do not have in hand.
Can you tell me more, or what do I have to do?

I need the speed of the ISR because I am also handling wireless communication in the ISR with the help of INT0 and CCP.

[Ttelmah]

Realistically, you are tying to go DIY, in a very complex area. There is no shortcut, you need to go through the entire listing file generated by the interrupt handler code, and identify every hardware register that is accessed (remember these are all in the top bank of the RAM, so identification is not that hard). Turn off the 'nolist' option in the header file first, so you also see registers accessed inside system calls. Add any RAM accesses to the first half dozen bytes of memory (this is the default location for the scratch area), Then cross off the W reg, status, and BSR, since you are using RETFIE 1, and you then need to save _every_ register left, and restore these on exit. Do not be suprised if you only end up saving half a dozen instructions over using the standard handler...

Best Wishes

[Remko]

Thank you for reply,

I have searched the LST of ISR and found several registers (All in the top of the area 0xF80 and higher, i am using 452 now and going to use 4620) There are the registers which I am bittesting for the int flags and bitclearing the int flags. There are timers and ccp pwm registers which I am modifying in the isr myself. The IntEdge is also there which I am modifying myself. There are only a few registers which I am not testing or modifying myself: FSR0H, FSR0L and INDF. I don't think I have to save and restore them do I? And the PRODL and PRODH registers. I have saved them but the problem still exists

My colleage advised me to change the buffer from a 8x18 array to a circular buffer of 144 and use the MOD function.

I already tried a little bit of this idea with string2[144]. Only filling the string does not give me the errors. The difference is the hardware multiplier.
I can go there but I must find out what goes wrong with the string[8][18].

This is the lst of the ISR which goes wrong:

beginning of the isr code:

[Remko]

All right, I misunderstood. It is about the scratch RAM which the compiler uses. The scratch RAM is used outside AND inside the ISR. While the program outside is using the scratch, an interrupt is generated and the ISR uses the same scratch area. That's right isn't it?
Because of the complex calculations ot the array of chars scratch has to be used. Simple calculation of a string[144] does not need the scratch.

How can I find out where the scratch is located?
How can I set the scratch addresses used in the ISR fixed to a location I choose instead of being chosen by the compiler?
It seems to be using address 0x00 till 0x04. 0x05 is used by a variable I put in, but it also uses address 0x2B6 and more.

[Ttelmah]

You _do_ need to save the FSR registers. INDF, is not a 'register' as such, but the contents of the memory addressed _by_ the FSR registers, so will automatically change when the FSR registers are saved/restored. The FSR, is used for all indexed addressing.
The scratch area is at the base of the RAM. Typically expect to have to save perhaps five values here. Look at the symbol map to see how many are used.
Also check you are not using the TBLPTR registers (get used for any ROM tables, and some types of switch statement).

Best Wishes

[Remko]

The first register begins an 0x05, it is Hekje. So I have to save 0x01, 0x02, 0x03, and 0,04.
What about the _RETURN_ ? Just save address 0x01 also?

[Remko]

I have changed my isr to see what the ccs compiler saves. W, Status and BSR are saved. The FSR registers are saved (6 pieces). The PROD registers are saved and the PCLATH is saved. Besides those, the scratch registers 00 till 04 are saved.
Now I understand, thank you for explaining.
You suggested me to look in my ISR and see which registers are used and save them.
In my ISR the registers FSR0L and H and the scratch registers 02 and 03 are used.
FSR0L and H and 03 are used in the RDA area.
02 and 03 are used in the Timer2 area.
To keep the highest speed I assume I have to save and restore them only in those areas.
Because of the fast return from interrupt I don't have to save W, Status and BSR, but what about PCLATH?

Is this what you mean in your former replies?
Is this right what you are saying in your former replies?

[Ttelmah]

PCLATH, only needs saving, if there is a 'computed GOTO' anywhere in the interrupt handler. This is used by some parts of the CCS code, which is why they save it. If nothing writes to it, you can leave it unsaved.
It sounds as if you have a fairly good list now of what is needed.

Best Wishes