dsPIC33 - Changing IPL - May this cause problems ?

[ggchab]

I wrote a small driver for a display based on an ili9488. Everything is running on a dsPIC33EV256M002.
I gave priorities to interrupts and any one of their handlers, up to level 3 (low frequencies interrupts), may have to write something to the display, in addition to the main loop running at IPL 0.

Drivers for i2c and uart never access the display and I gave the corresponding interrupts a priority of 5.

I don't want to queue the requests to write to the display because this could take to much RAM. As some sections of the ili driver code cannot be interrupted (they can, but not to do other things with the ili9488 chip), I decided to "artificially" raise the IPL to 4 when I am running those sections of code. Can this cause any problem ? Thanks for any advice.

Code: [Select]

static uint16_t IPLbits;

static void LCD_SetIPL ()
 {
  __builtin_disable_interrupts();
  IPLbits = SR & 0b0000000011100000;
  SR = (SR & 0b1111111100011111) | 0b0000000010000000;  // 0b100 = 4
  __builtin_enable_interrupts();
 }

static void LCD_RestoreIPL ()
 {
  __builtin_disable_interrupts();
  SR = (SR & 0b1111111100011111) | IPLbits;
  __builtin_enable_interrupts();
 }


[NorthGuy]

Can this cause any problem?

I don't think so.

It, sort of, defeats the purpose of having interrupts of different priorities because now the interrupts with high priority would have to wait until low priority interrupts finish with LCD. If such inversion of priorities is Ok, it would be easier to just assign the priority of 4 to all involved interrupts.

But anyway, such manipulation does not create any fundamental problems and should work as you expect it to work.

[ggchab]

Thanks. I have to look somewhere else for random freezing of my application !
I could also see this IPL change as if the ili9488 chip could generate some interrupt to which I would have assigned priority 4.

[Janus]

Are you satisfying both the watchdog and deadman interrupts?  As a first pass I would but put some debug code in your FLIH (First Level Interrupt Handler) to see if your random freezing is even interrupt related.

[NorthGuy]

I have to look somewhere else for random freezing of my application !

Run it under debugger. Once it freezes, halt it and see what it's doing.

[ggchab]

I can make it freezing during a debugging session but then, the debugger halts and I can't obtain any interesting information. MPALAB/PICKit can't even see the PIC anymore. I have to power off/on my board 
Watchdog is disabled.

[NorthGuy]

I can make it freezing during a debugging session but then, the debugger halts and I can't obtain any interesting information. MPALAB/PICKit can't even see the

If debugger cannot see it any more, then it probably resets. If that's the case, it'll boot up again and you'll be able to read the cause for the reset from the RCON register.

[ggchab]

Thanks ! POR and BOR bits are set to 1 and the 5V supply is only 4.6V and 3.3V is 3V. The bridge rectifier becomes very hot !
The input of the 3.3V regulator is connected to the 5V and used only for the LCD (ili9488 compatible Arduino display). This is a L4931 and it should still provide 3.3V even if its input is 4.6V. So, I guess something is going horribly wrong with the ili9488 display ...

What I still don't understand is why this is happening randomly, when doing repeatedly a specific operation that calls a function to write text on the display, function called from many other places where it works perfectly (at least, I couldn't reproduce the same problem although I tried very hard)

[ggchab]

Solved by a spare display One day lost trying to fix a non existing problem but a good lesson learned !
Many thanks again.

[NorthGuy]

What I still don't understand is why this is happening randomly, when doing repeatedly a specific operation that calls a function to write text on the display, function called from many other places where it works perfectly (at least, I couldn't reproduce the same problem although I tried very hard)

If it is hovering just above BOR, it won't be very predictable. The moment when/if if finally dips through and causes the reset will be more or less random. If you find out what's draining the power, it won't be difficult to figure out how the software may cause it (if it is indeed the software).