Interruption priority problem

[Manel28]

Yes, I know what you mean. A Circular buffer should be a better option.
I was talking about priorities becouse I just made a test commenting Timer1 handler code and it seems to receive all bytes without any corrupted bit even by using a linear buffer. I can assume then that the Timer1 interruption affects the 19byte packet reception.
Should I set priorities then?
The amazing world og the microcontrollers :D. Anyway thanks for your help

[Ttelmah]

How fast is your baud rate?.
What is your clock rate?.
Did your 'test' perform the actual buffer handling operation from the external code?. As I say, I suspect this is the real 'heart' cause of the problem....

The simplest 'priority' method, is just to declare the timer interrupt after the INT_RDA. This makes the compiler test the RDA bit _first_ in the global handler code.
Second method is to use the hardware high priority ability. Whether you can use this will depend on whether you are using any other interrupts, in particular INT_EXT.
Provided you are _not_ using INT_EXT, you just need to add "#device HIGH_INTS=TRUE" to the top of your source code, and declare INT_RDA as "#INT_RDA HIGH".

Best Wishes

[Manel28]

The baud rate is 19200 bps and the clock ist 40MHz (#use delay(clock=40M, oscillator=10M) #fuses H4_SW,NOWDT,NOPROTECT,NODEBUG).
The test I´ve made consist of sending 19 bytes packets every 70ms at 19200bps. It seems to receive all data perfectly when commenting timer code and if I add it again the data get corrupted. I was thinking about disabling timer interruptions inside the rda interruption handler..may be it could be a solution

[Ttelmah]

No.
All interrupts are already disabled in each other interrupt handler (unless you are using high ints).
Enable warnings when you compile the code. Now, do you have any 'interrupt disabled' warnings?. Do any appear/disappear if you enable the timer code?.
What you show for the timer, should have no effect whatsoever.
However, some different RDA code:

[Manel28]

No. I don't get any interrupt disabled warning when I compile the code. Now arises a new problem. As I said, the idea is to make a serial-ethernet converter and i was following the code of the tcp stack ex12.c.
The code when I put the serial received packets was something like:

[Manel28]

I add also the setup in the main function. Maybe I'm doing something wrong:

[Wayne_]

is lenbuff2 a var or a #define or const ?

in this case it would usually be a #define which would reduce the code required when compiled. if it is a var then the compiler has to treat it as a variable that may change its value which results in more code.

I doubt this is your problem, just an observation.

[Manel28]

It is defined as static int const. I have just tested it again but now with circular buffer with the rda_int code Ttelmah told me and I get the same behaviour..quite strange. I am 90% sure there is something the timer1 does that corrupts the received bytes..like interruptions during receiving process and thats why the data is bad. Again I've simulated the reception commenting this lines :

[Ttelmah]

I see the comment _simulated_. What simulator?. Have you tried an actual chip?.
You may be chasing a simulator problem...

Best Wishes

[Ttelmah]

Other thing is that presumably the timer code triggers _something_ externally, when you set 'temp'. What does this do?. The problem could be that something in this code, walks over part of the RAM, and corrupts values....

Best Wishes

[Manel28]

Hi again, I think Im getting closer to the problem. The "temp" variable you are asking for is a flag which activates a function inside the main process. You are right. The problem is not the interruption itself but the following process executed due to temp=1. Something like:

while(TRUE) {
StackTask();
UDPTxTask();
UDPRxTask();

if(temp==1)
putc('A');
putc('B');
putc('C');
putc('D');
putc('E');
putc('F');
putc('G');
putc('H');
putc('I');


}

At the same time I'm receiving through the Rx line 19bytes. The problem in fact is the rs232 behaviour. If I make for example if(temp==2) so that putc() does not execute I receive the 19 bytes perfectly.

I have defined :

#use rs232(baud=19200, parity=O, bits=8, xmit=PIN_C6, rcv=PIN_C7)

[Manel28]

I forgot to say I'm using mplab icd 2 to debug the code

[Ttelmah]

I'd have expected it to start working with the larger (32character) buffer.
Problem is that when 'temp==1', you may not 'see' this for the time taken to execute three tasks - how long do these take?. You need to use the debugger and _time_ the total these take to execute, and then you send 9 bytes (why not just use 'putc("ABCDEFGHI";', or a printf?), _before_ you start looking for the next packet in your code. Also, you don't show the code setting temp _back_ to zero. This should be the first line after the 'if (temp==0)' test. Now with the 32 character buffer, you can receive 18 characters after 'temp' is set, before an effective overflow would occur.

Best Wishes

[Manel28]

I see the problem only when it executes putc function. I have done:

[Ttelmah]

Use ex_stisr.c.
Serial interrupt driven _transmit_ buffer.
Then your code only needs to load the output data, and the interrupt sends it.

Whatever you do though, the sequence should be: