• AVR Freaks

Hot!MCC Coretimer implementation for PIC32MM: potential dangerous bug

Author
jesselackey
New Member
  • Total Posts : 16
  • Reward points : 0
  • Joined: 2010/06/11 23:13:06
  • Location: 0
  • Status: offline
2020/09/25 04:19:40 (permalink)
0

MCC Coretimer implementation for PIC32MM: potential dangerous bug

Hi all, after spending 4-ish hours on this, I wanted to warn anyone looking for Coretimer support with MCC that Microchip's implementation is dangerously naive.  I configured MCC to give me an interrupt every 1msec for a PIC32MM running at 24Mhz, and the code below was generated.  Works fine, until...
...until you disable interrupts for longer than 2msec, at worst.  The problem could happen with disabling them for just over 1msec.
Here's what happens.  In the code below, when the coretimer interrupt happens, the Coretimer's COMPARE is advanced another 0x2EE0 (i.e. 1msec), as the Coretimer's COUNT just continues on since it is always running.  No problem, as long as you service the interrupt quickly.  However: if interrupts are disabled for 2msec, and then this ISR runs when they are re-enabled, guess what: the COMPARE is set to a value that the COUNT has already passed!  So that's it, you're dead ... until the COUNT wraps in 15 minutes thereabouts.
 
A real bad potential bug.  And what would do this?  Any erases to flash memory, which requires interrupts to be disabled, at least according to the datasheet and Microchip's flash handler code made by MCC.  (And anything else you might have in your design.)
 
So using Coretimer as the prime timing source with 1msec resolution (as is typical) may be a real issue in your design.  Just warning everyone of this unexpected gotcha with MCC generated code.
 
Microchip: adding any words of caution in the MCC generated code would have saved a bunch of grief.  There is no expectation that this timer implementation would break based on disabling interrupts for 2X longer than the call period.  The code tries to make it look like a conventional timer, where that of course wouldn't happen, and fails.
 
J
 
 
 
void __attribute__ ((vector(_CORE_TIMER_VECTOR), interrupt(IPL1SOFT))) _CORE_TIMER_ISR(void)
{
uint32_t static compare = 0x2EE0;
// Update the compare value
compare = compare + 0x2EE0;
_CP0_SET_COMPARE(compare);

IFS0CLR= 1 << _IFS0_CTIF_POSITION;
// Add your custom code here
}
#1

11 Replies Related Threads

    JPortici
    Super Member
    • Total Posts : 1174
    • Reward points : 0
    • Joined: 2012/11/17 06:27:45
    • Location: Grappaland
    • Status: offline
    Re: MCC Coretimer implementation for PIC32MM: potential dangerous bug 2020/09/25 04:30:54 (permalink)
    +1 (1)
    duh?
    the code from MCC is correct. It's the Core Timer implementation that sucks, but that comes free with CP0.
    And the issues with its implementation are obvious to anyone reading how it works in the datasheet.
     
    If i must use it it's just to timestamp things.
    TMR1 is doing the system timer in every 16 and 32bit project, TMR2 (or 4) in 8bit projects
    post edited by JPortici - 2020/09/25 04:33:25
    #2
    jesselackey
    New Member
    • Total Posts : 16
    • Reward points : 0
    • Joined: 2010/06/11 23:13:06
    • Location: 0
    • Status: offline
    Re: MCC Coretimer implementation for PIC32MM: potential dangerous bug 2020/09/25 10:28:22 (permalink)
    +1 (1)
    That's the point.  I should not need to read not just the datasheet (says almost nothing), but the MIPS CPU documentation, to find out that Microchip's MCC wrapper does not do what it says it does: generate a periodic interrupt at the user specified rate in a assured manner.
    I understand that Microchip isn't going to change their 4-line ISR.  This is here for other developers to find as they search for why their system has issues with the out of the box MCC wrapper for Coretimer.
    J
    #3
    NKurzman
    A Guy on the Net
    • Total Posts : 18975
    • Reward points : 0
    • Joined: 2008/01/16 19:33:48
    • Location: 0
    • Status: offline
    Re: MCC Coretimer implementation for PIC32MM: potential dangerous bug 2020/09/25 10:54:13 (permalink)
    0
    That is the Problem with trying to make "universal" Embedded code.  It is hard to make one size fits all.
    I assume that can be fixed, You may want to report the Issue.
    You would still be stuck with how do you deal with the lost ticks.
    But the fix would slow down the interrupt handler.
    Or you can code around it.
     
    #4
    jesselackey
    New Member
    • Total Posts : 16
    • Reward points : 0
    • Joined: 2010/06/11 23:13:06
    • Location: 0
    • Status: offline
    Re: MCC Coretimer implementation for PIC32MM: potential dangerous bug 2020/09/25 11:43:59 (permalink)
    0
    Tx NKurzman, I coded around it, and submitted a ticket.  All they need to do is add a single sentence in their generated code addressing this deficiency.
    J
     
    #5
    NKurzman
    A Guy on the Net
    • Total Posts : 18975
    • Reward points : 0
    • Joined: 2008/01/16 19:33:48
    • Location: 0
    • Status: offline
    Re: MCC Coretimer implementation for PIC32MM: potential dangerous bug 2020/09/25 12:55:03 (permalink)
    0
    That would depend on how many ticks you missed, and if the timer rolls over.
    Clearing the timer and starting over would make it impossible to use the Core timer as a way to measure time by using the Core timer as a free running system timer.
    Does you solution solve everyone's issues.
    #6
    JPortici
    Super Member
    • Total Posts : 1174
    • Reward points : 0
    • Joined: 2012/11/17 06:27:45
    • Location: Grappaland
    • Status: offline
    Re: MCC Coretimer implementation for PIC32MM: potential dangerous bug 2020/09/25 15:49:25 (permalink)
    +1 (3)
    jesselackeyI should not need to read not just the datasheet (says almost nothing), but the MIPS CPU documentation

    balls.
    Read the fucking documentation. Or get another job if you want to be lazy.
    code generators are not substitutes for knowledge. Code generators are there to create boilerplate so you don't need to.. but to write your own is always better so most code generators (a la MCC or CUBE MX) are in fact useless.
     
    I abide the use of generators that provide certified code so you can  prove it's certified but the cost of such tools is just ludicrous.
     
    , to find out that Microchip's MCC wrapper does not do what it says it does: generate a periodic interrupt at the user specified rate in a assured manner.

    it does. but with a catch, and everyone using MIPS (and others using simillar implementations of core timer, it's not just MIPS unfotunately) knows it.
     
    I understand that Microchip isn't going to change their 4-line ISR.

    and they don't have to, because it works in the restricted domain in which it's acceptable
    #7
    jesselackey
    New Member
    • Total Posts : 16
    • Reward points : 0
    • Joined: 2010/06/11 23:13:06
    • Location: 0
    • Status: offline
    Re: MCC Coretimer implementation for PIC32MM: potential dangerous bug 2020/09/25 20:09:47 (permalink)
    -1 (1)
    I knew I'd get a response like that - uncalled for vitrol, and with swearing even!  The technical content of the message is not worth discussing with you.
    J
    #8
    JPortici
    Super Member
    • Total Posts : 1174
    • Reward points : 0
    • Joined: 2012/11/17 06:27:45
    • Location: Grappaland
    • Status: offline
    Re: MCC Coretimer implementation for PIC32MM: potential dangerous bug 2020/09/25 21:12:19 (permalink)
    +1 (1)
    And i was kind of expecting this response, because you can't handle the truth.
    (see, i can also quote movies ;) )
     
    you are a firmware developer. As long as you keep doing only the high level stuff go ahead, ignore the hardware.
    but the moment you touch it you have to know what you are going to do, i.e.: read the docs.
    code generators that touch the hardware are no substitutes for knowing the hardware, despite whatever the marketing material promises. But they are doing marketing what do they know, right? 
     
    Anyone that has a tiny bit of knowledge of this particular timer will tell you the same thing: it's not designed for periodic interrupts. It can be used for that but it's not its purpose, period.
    Someone claim it's a bug? i claim that someone doesn't know what is talking about.
    #9
    acharnley
    Super Member
    • Total Posts : 617
    • Reward points : 0
    • Joined: 2016/05/01 06:51:28
    • Location: 0
    • Status: offline
    Re: MCC Coretimer implementation for PIC32MM: potential dangerous bug 2020/09/26 04:28:27 (permalink)
    +2 (2)
    There are tons of bugs in the MCC code which don't work around quirks in the hardware and you shouldn't rely on what it generates. Here's two nice ones -

    1. Configures CWG PPS before enabling CWG creating a short when the CWG is controlling a PMOS+NMOS buck.

    2. Initialises and enables digital peripherals that may use analog peripherals before analog peripherals like FVR & DAC are ready potentially latching CLC's in SR/JK mode and setting 'false' interrupt flags.
     
    Also to say this is dangerous is hyperbole, you shouldn't rely on any software implementation for critical control.
    post edited by acharnley - 2020/09/26 04:31:19
    #10
    kaamil1984
    Junior Member
    • Total Posts : 45
    • Reward points : 0
    • Joined: 2014/05/01 14:02:25
    • Location: Chair at the desk in my workshop ;)
    • Status: offline
    Re: MCC Coretimer implementation for PIC32MM: potential dangerous bug 2020/10/07 16:36:15 (permalink)
    0
    This is not a bug Sir. I also had such idea (to use CORETIMER to generate system ticks), but...
     
    CORETIMER is very bad idea to generate periodic interrupts (like 1ms).
     
    This is very simple timer/counter. It cannot be stopped, it cannot be set to some value etc. All you can do with it is to set compare value.
     
    To write periodic interrupt you need regular timer (like TMR0).
    #11
    Mysil
    Super Member
    • Total Posts : 3796
    • Reward points : 0
    • Joined: 2012/07/01 04:19:50
    • Location: Norway
    • Status: offline
    Re: MCC Coretimer implementation for PIC32MM: potential dangerous bug 2020/10/07 18:37:20 (permalink)
    0
    Hi,
    I have used the core timer in PIC32MX... successfully,
    but I understand how it work, and take precautions when needed.
    I do not depend on MCC to take care of every detail, I review generated code and make corrections to my preference.
     
    I do not often use Flash program memory write,
    but when a Flash memory write is completed, Compare register can be updated by reading the actual Count register value and use that to calculate new Compare register value.
     
    If wanted, this may be done in core timer interrupt handler, by checking that new Compare value really is in the future when compared to Count register.
    But this may not be needed for every interrupt if you know what events may cause this state.
     
    The core timer can be stopped and started, and it can be reset. The debugger (hardware) do that all the time.
    In application code it is a bad idea to mess with the Count register value, and it is not needed.
     
        Mysil
    post edited by Mysil - 2020/10/07 18:39:22
    #12
    Jump to:
    © 2020 APG vNext Commercial Version 4.5