Darrel Taylor Interrupts I2C Problem

[dcorraliza]

Hi Mr Taylor:

I agree with you about the difficult task of introducing interrupts on a big program, but I think the problem isn't there.

Following your recommendations I have extract the core lines of my program, just to test the interrupts, so my lite-version is that:

DEFINE LOADER_USED 1
iNCLUDE "cfgvtol-MIXER_18f2685_40mhz.bas"
INCLUDE "DT_INTS-18.bas"
INCLUDE "ReEnterPBP-18.bas"


DEC_MICRO:
DEFINE I2C_HOLD 1

ADCON1 = %00001111

PORTA = 0
TRISA = %111101
PORTB = 0
TRISB = %00000001
PORTC = 0
TRISC = %10000100
PORTE = 0

I2C_RDR_SCL VAR PORTC.3 ' I2C Reader clock
I2C_RDR_SDA VAR PORTC.4 ' I2C Reader data

RDR_I2C_DIR_SLAVE con $24
RDR_I2C_BUFFER_SIZE con 32
RDR_I2C_BUFFER var byte[RDR_I2C_BUFFER_SIZE]
RDR_FLAG VAR BIT
RDR_AUX VAR Byte
RDR_VALUE VAR WORD

ASM
INT_LIST macro ; IntSource, Label, Type, ResetFlag?
INT_Handler INT0_INT, _INT_READER, PBP, yes
endm
INT_CREATE ; Creates the interrupt processor
ENDASM
@ INT_ENABLE INT0_INT ; enable external (INT) interrupts

RDR_FLAG=0

LOOP:
if rdr_flag then
for RDR_AUX=0 to RDR_I2C_BUFFER_SIZE-1 step 2
RDR_VALUE.lowbyte = RDR_I2C_BUFFER[RDR_AUX]
RDR_VALUE.highbyte = RDR_I2C_BUFFER[RDR_AUX+1]
hserout[dec RDR_VALUE, tab]
next RDR_AUX
hserout [cr, lf]
rdr_flag=0
endif
GOTO LOOP

INT_READER:
I2CREAD i2c_rdr_SDA, i2c_rdr_SCL, rdr_I2C_DIR_SLAVE , [str RDR_I2C_BUFFER\RDR_I2C_BUFFER_SIZE], INT_READER_ERR
RDR_FLAG = 1
INT_READER_ERR:
@ INT_RETURN

This program only waits for an interrupt in the RB0 port and then performs an I2CREAD. If the I2CREAD has success a flag is activated.

In the main loop, we just look for the flag to change, and then the data received is sent through the serial port.

As you said, defining a new variable on your code, makes no changes (my mistake), but restoring FLAG var still is the clue. If FLAG var is restored, the i2cread is only executed properly the first time, and if I delete that line (I know that isn't right, but is used to investigate) I2CREAD is executed every 20ms (the right frame)

Following that trail, I have introduced some dummy vars to obtain FLAGS var status in different moments of the interrupt:
FLAGS=00100000 When being saved for the first time.
FLAGS=01100000 After I2CREAD has being executed.
FLAGS_SaveH=00000100 Line before restoring FLAG, is a little strange because FLAGS was 00100000 when was saved (When was FLAGS_SaveH modified?????)
FLAGS=00000100 After restoring
If that value is restored, I2CREAD don't work any more.

As I have said, if we don't restore the FLAGS var I2CREAD keeps working, leaving FLAGS=01100000

I hope you can help me with this reduced program that shows something strange happening.

Maybe is a nonsense, but value of FLAGS_SaveH when saved (00100000) and when restored (00000100) is the same value with inverted alignment, ?????

Thanks in advance,

dcorraliza

[dcorraliza]

Hi all:

Finally the problem has an explanation, and I feel I have found it. Has been a lot of hours trying to understand this strange behaviour, but at least I caught it.

The question was easier that it seems, it was an "initial" condition, the one that makes all go bad. The first time an interrupt was handled disable the I2CREAD routine. The clue was in the values tracked by me of:

FLAGS=00100000 When being saved for the first time.
FLAGS=01100000 After I2CREAD has being executed.
FLAGS_SaveH=00000100 Line before restoring FLAG, is a little strange because FLAGS was 00100000 when was saved (When was FLAGS_SaveH modified?????)
FLAGS=00000100 After restoring

In this previous paragraph I take notice that the value that was saved on FLAGS_SaveH wasn't the same when we tray to restore it, and I said: When was FLAGS_SaveH modified?????
This is a wrong question, the question is: Was FLAGS saved on FLAGS_SaveH? And the answer is NO. This flag var was not saved, because on top of "SavePBP_H:" routine we only save vars if VarsSaved_H = 0. And this is the reason, VarsSaved_H wasn't initialized at the beginning of the program so depending on the compilation it could have a "0" (Like when I added de "nothing" var) and make all work properly, or a "1" that makes the first interrupt handling not to save previous values, and then restoring rubbish ones.

My workaround is to add a initialization line under variable definition:
DEFINE ReEnterHPused 1
VarsSaved_H VAR BIT
VarsSaved_H=0 <-------ADDED

But maybe Mr Taylor, can help me to know if this initialization should be done on INT_ENABLE routine, to ensure its value every time we enable interrupts. What do you think Mr Taylor?

That's all for now, I hope all of you have enjoyed the mystery resolution, as I do...

Greetings,
dcorraliza

[Darrel Taylor]

Still looking at my program for your problem I see.

VarsSaved_H is a flag that gets set when ever the Instant Interrupt system saves PBP's System variables in a High Priority interrupt.

With complex programs using both ASM and PBP type handlers, it allows the system to only save and restore the system variables when it needs to.

You are only using a single PBP type interrupt. That bit will always be set on entry to the interrupt handler, And is cleared after the handler has finished. Initializing it to 0 will not do anything.

The only way it could possibly have an affect on your program, is if you have enabled Interrupts that do not have an associated handler.

So anyhow, what are you reading with the I2C statement. (what chip)
<br>

[dcorraliza]

Hi Mr Taylor:

Please, don't think I'm trying to put my problems on your program, be sure I'm not looking for a guilty, I'm just trying to find a workaround to my problem. Your software is great, and that's what I'm using it, but I have an issue I need to fix. Maybe I need to change the post subject, because I'm not sure where the problem is.

If you are asking me for the I2C slave, is an specific purpose pic, reading analog inputs and sending it digitalized by I2C protocol, every 20ms.

Talking about my previous post, I know that VarsSaved_H is set every time you start the handle of an PBP High Priority interrupt. But I can see in your code that you only save the variables "if VarsSaved_H = 0 then" so if VarsSaved_H=1 when you enter the "SavePBP_H" routine you don't save then and VarsSaved_H keeps its value to 1. At the interrupt handling exiting the program again look for VarsSaved_H state to know if it needs to restore variables, as the system see VarsSaved_H=1 it restores some value that nobody has set.
As long as I can see VarsSaved_H is not initialized anywhere before entering "SavePBP_H" for the first time, so we can't know what value it has. If it is 1 then the problem appears. Are you agree?

I don't have any doubt that maybe my program has another problems, or maybe the I2C slave is generating me other issues, but I think that VarsSaved_H initialization should be done for a right execution.

To end, please accept my apologies if my English isn't good enough and you misunderstood my intentions. I'm just trying to find a solution to my problems, and making it public to maybe help other people

Greetings,
dcorraliza

[Darrel Taylor]

OK, I see what you're saying dcorraliza.

I always have a CLEAR statement at the beginning of the program, so it's never been a problem for me.

I should add your suggestion, for the people that don't use Clear.

Sorry for the thick head.
Thanks for the persistence.

Darrel

Added:
&nbsp; I'll also be adding INT_Flags = 0 to the DT_INTS.bas file.
&nbsp; Thanks again.

[Darrel Taylor]

I imagine there are a lot of people that don't have CLEAR in their programs, so I'm glad you found that dcorraliza.

I've updated the DT_INTS-18 files to version 3.3

You can find the new version here ...
http://darreltaylor.com/DT_INTS-18/downloads.html

Thanks again,