Beta 7.3.0 - interrupts

[janni]

After I finally succeeded in setting Multi-vector enabled interrupts and have IVT-enabled as interrupt mode (starting state in Project Edit window is Multi-vector enabled and Legacy Mode ) the Interrupt Assistant started to show vectored interrupts options (hurrah!).

Naturally, I immediately tried to change the vector base, which isn't possible . Please make it adjustable - otherwise the vector table will collide with low-side bootloaders (and protected boot blocks start from 0).

Unfortunately, the Interrupt Assistant still needs some work. K42 and K83 processors have two sets of shadow registers, for both priority levels. With ICS_AUTO the Interrupt Assistant for some reason uses own registers for context saving of basic registers (used for low priority interrupt in older processors), and therefore ends the ISR with RETFIE 0. Obviously, there's no need for additional context saving of basic registers and interrupt routines should end with RETFIE 1, letting the hardware restore basic registers, whatever is the interrupt priority of particular source.
In my opinion, even with ICS_OFF the ISR should end with RETFIE 1 - this option should only mean that compiler will not attempt to save context of any other registers.

It would be easier (for us users, naturally ) if interrupt sources were listed alphabetically in Interrupt Assistant (unlike in Library Manger where alphabetical ordering should be optional - I'll be complaining about it, till it gets resolved ).

BTW, the interrupt priority enable bit, IPEN of INTCON, is missing in processor definition files.

[rajkovic]

Janni thanks on feedback,

We will add possibility to edit and move vector base from edit project, for now you can do that from your code


We have somehow missed to document changes in help for BETA, sorry for that.
there is also keyword for declaring priority level of interrupt when you use IVT



ilevel const_value

const_value can be 0 or 1
0 high priority level
1 low priority level

this only declares priority level for linker to know how to handle interrupt routine context saving and return
and bit in register still must be set manually

Code: Select all

void Test() iv IVT_U1TX  ilevel 0 ics ICS_AUTO {
  PIR3.U1TXIF = 0; // Clear the interrupt flag
}

[janni]

We will add possibility to edit and move vector base from edit project

Great .

there is also keyword for declaring priority level of interrupt when you use IVT

That's why compiler assumed low priority (it still shouldn't block processor from using the shadow registers though).

this only declares priority level for linker to know how to handle interrupt routine context saving and return and bit in register still must be set manually

Understandable.

BTW, it would be nice if simulator filled vectored interrupts' registers, like IVTBASE and IVTAD with values.

[rus51]

Hi mE

During testing of MikroC V7.3.0 on an 18F27K42, a few strange problems have become apparent with different combinations of interrupts. During all testing I used 2 peripherals, TMR0 interrupting and toggling a led every 330 ms and Uart2 (with 3 ints on rx,tx and framing error) set up as an echo transceiver at 9600 baud. The same interrupt code (as far as possible) is used in all programme code for all combinations of interrupts. The main programme loop code displays a running 32 bit counter on a TFT lcd.

I tested the following combinations.

1. Legacy Mode....TMR0 hi int, U2 RX hi int, U2 TX hi int, U2 framing error hi int.
This combination worked without apparent problems. The main programme loop continued to run and display the running counter without fault. The led toggled off and on and the echo transceiver ran continuously without fault.


All the rest of the tests below showed the same fault. The main programme loop failed after 20 or 30 loops and the screen froze. However, the led continued to toggle off and on and the echo transceiver continued to run without fault. Testing showed that the mcu was not attempting to write to the lcd (via SPI1).

In other words, the interrupts continued to run normally but the main programme loop stopped after a few cycles. Is it possible that there is a problem with restoring registers after an interrupt and the available stack RAM is quickly used up?

2. Legacy Mode....TMR0 hi int, U2 RX lo int, U2 TX lo int, U2 framing error lo int.
3. Legacy Mode....TMR0 lo int, U2 RX lo int, U2 TX lo int, U2 framing error lo int.
4. IVT Mode....TMR0 hi int, U2 RX hi int, U2 TX hi int, U2 framing error hi int.
5. IVT Mode....TMR0 hi int, U2 RX lo int, U2 TX lo int, U2 framing error lo int.
6. IVT Mode....TMR0 lo int, U2 RX lo int, U2 TX lo int, U2 framing error lo int.

I have no more time to carry out more testing.

rus51

[rus51]

Hi mE

An update to my previous report on interrupt testing with MikroC Pro V7.3.0 and a PIC18F27K42.

By using the addition of "ilevel" (with either 0 or 1) in the definition of the IVT interrupt functions, I have had success in getting IVT interrupts working only when all the interrupts are low priority.

So the revised results of my testing are as follows:

//======================================================================================
Test 1. Legacy Mode....TMR0 hi int, U2 RX hi int, U2 TX hi int, U2 framing error hi int.
Test 6. IVT Mode....TMR0 lo int, U2 RX lo int, U2 TX lo int, U2 framing error lo int.

Both these combinations worked without apparent problems. The main programme loop continued to increment and display the counter without fault. The led toggled off and on and the echo transceiver ran continuously without fault.
//======================================================================================
Test 2. Legacy Mode....TMR0 hi int, U2 RX lo int, U2 TX lo int, U2 framing error lo int.

This combination ran everything well until the Uart2 echo transceiver received input. It then froze the main loop, however both the transceiver and the timer0 (led flash) interrupts continued to function normally.
//======================================================================================
3. Legacy Mode....TMR0 lo int, U2 RX lo int, U2 TX lo int, U2 framing error lo int.
4. IVT Mode....TMR0 hi int, U2 RX hi int, U2 TX hi int, U2 framing error hi int.
5. IVT Mode....TMR0 hi int, U2 RX lo int, U2 TX lo int, U2 framing error lo int.

These three tests showed the same fault. The main programme loop failed after 10 to 30 loops and the screen froze. However, the timer0 driven led continued to toggle off and on and the echo transceiver continued to run without fault. In other words, the interrupts continued to run normally but the main programme loop stopped after a few cycles.

Is it possible that there is a problem with restoring registers after an interrupt and my main programme loop is being sent into an error trap loop?
//======================================================================================

If mE would like to look at the test programmes that I have used and see the results for themselves, please give me an email address to which I can send them.

rus51

[filip]

Hi,

You can send the test programs to my e-mail address, filip att mikroe dot com.

Regards,
Filip.

[rus51]

Hi Janni

I sent my test programmes to Filip (as requested by Filip) on 08/02/2019 and since then I have heard absolutely nothing from Filip, even though I emailed him asking for some preliminary or likely reason for the erroneous performance of some of my programmes on the 18F27K42. If you would like to contact me at ""engineer@activ8.net.au", I would like to send these test programmes to you so that you can evaluate their operation. They may help you find more undetected faults in the compiler.

Regards
rus51

[janni]

Hi,
I'd like to see the code, naturally . I'll send you a message.

[rus51]

Hi Janni

I tried dropping the zip file into google disk but I kept receiving a message telling me that I had no authority to upload files. I have sent the zip file to the email address you used.

Regards
rus51

[janni]

I have sent the zip file to the email address you used.

Sorry for the trouble and thanks for the files. Your examples show that not only compiler unnecessarily saves/restores the basic registers (as I mentioned in the first post here), it also leads to errors when low priority interrupts are serviced.

Besides other registers, compiler unnecessarily saves (and later restores) the W register in low priority ISR. Unfortunately, in K42/K83 processors the W register is overwritten after being stored in its shadow register, so the compiler saves and restores wrong value. It can be overruled in case of vectored interrupts where ilevel 1 (high priority) may be declared, whatever the real interrupt priority. However, in case of legacy interrupts ilevel keyword is ineffective, so one may only use legacy interrupts without priority (or only high priority interrupts, which is effectively the same).

Naturally, one may write ISRs exclusively in assembly and block all compiler intervention with ics ICS_OFF (or pragma disablecontextsaving), but that's probably a convenient solution only for fanatics, like myself.

[rus51]

Hi Janni

I thank you most sincerely for the work you have done to find the reason(s) for the mC K42 interrupt problems. Your knowledge of the PIC18 architecture and of PIC assembly language is impressive. I hope that the pic compiler team members at mE take notice.

rus51

[rus51]

Hi Janni

I have confirmed that what you have found is correct.

"ilevel 1" is now correctly identified by you as high level, not low level as written by mE.

With IVT interrupts.
If the interrupt is declared as "ilevel 1" regardless of what the IPR register bit setting is, the return from interrupt restoration of registers is valid and the main programme loop and all interrupts work as expected.

With Legacy Interrupts.
The return from interrupt restoration of registers is only valid when INTCON0.IPEN = 0. That is when priority disabled = all interrupts high.

Many thanks
rus51

[janni]

Thanks for confirmation but I'm afraid that my ad hoc solution of using only ilevel 1 is not a complete workaround. It'll work fine if ISRs of only one interrupt priority use internal compiler registers (like in your examples). In other words, functions of one of the priorities have to be pretty simple, so compiler will have no need to use its special registers (called Rx and placed at the start of data memory). More complex statements and arithmetic involves the use of these registers and ISRs of different priorities require separate buffers for them.

What needs to be done is reduction of registers saved/restored by compiler to compiler's own internal registers (Rx ones) as all other necessary registers (even those compiler does not rutinely save in older processors) are already included in hardware context saving of K40 and K83 processors. Compiler will then need the ilevel keyword only to decide which buffer of its internal registers to use.

BTW, these new processors even have a basic set of shadow registers for subroutine calls which compiler could use, or at least enable to use by some keyword forcing compiler to replace standard call/return instructions with 'FAST' ones.

[filip]

Hi,

I have reported all of your findings to our developers, it should be solved in the next release.

Regards,
Filip.