dsPIC33 - Changing IPL - May this cause problems ? - Page 1
Forum section: electronics / general

author: ggchab
author_rank: Frequent Contributor
timestamp: November 30, 2017, 09:13:35 am
content: 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: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();}

author: NorthGuy
author_rank: Super Contributor
timestamp: December 01, 2017, 02:00:58 am
content: Quote from: ggchab on November 30, 2017, 09:13:35 amI 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.

author: ggchab
author_rank: Frequent Contributor
timestamp: December 01, 2017, 08:41:57 am
content: 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.

author: Janus
author_rank: Newbie
timestamp: December 01, 2017, 11:27:07 am
content: Are you satisfying both the watchdog and deadman interrupts? As a first pass I wouldbutput some debug code in your FLIH (First Level Interrupt Handler) to see if your random freezing is even interrupt related.

author: NorthGuy
author_rank: Super Contributor
timestamp: December 01, 2017, 02:21:06 pm
content: Quote from: ggchab on December 01, 2017, 08:41:57 amRun it under debugger. Once it freezes, halt it and see what it's doing.

author: ggchab
author_rank: Frequent Contributor
timestamp: December 01, 2017, 04:05:35 pm
content: 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 boardWatchdog is disabled.

author: NorthGuy
author_rank: Super Contributor
timestamp: December 01, 2017, 04:47:01 pm
content: Quote from: ggchab on December 01, 2017, 04:05:35 pmIf 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.

author: ggchab
author_rank: Frequent Contributor
timestamp: December 01, 2017, 05:48:04 pm
content: 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)

author: ggchab
author_rank: Frequent Contributor
timestamp: December 01, 2017, 06:08:25 pm
content: Solved by a spare displayOne day lost trying to fix a non existing problem but a good lesson learned !Many thanks again.

author: NorthGuy
author_rank: Super Contributor
timestamp: December 01, 2017, 06:16:55 pm
content: Quote from: ggchab on December 01, 2017, 05:48:04 pmIf 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).