• AVR Freaks

Hot!dsPIC33EP512MU814 resets when debugging code in auxiliary flash

Author
hbouchard
New Member
  • Total Posts : 8
  • Reward points : 0
  • Status: offline
2019/10/11 02:03:38 (permalink)
0

dsPIC33EP512MU814 resets when debugging code in auxiliary flash

Hi,

I'm using a dsPIC33EP512MU814 chip. I'm developping a bootloader which will run in auxiliary flash memory. When I started testing it with ICD3 to step through my code, I first hit "pause" then check what I wanted to check and hit "play" again but for no obvious reason, the dsPIC reseted.
 
I created a test project to recreate the problem which arise every times by just halting and restarting the execution of the code. I've attached the main.c, linker script and project options (renamed *.txt) to this post.
 
It seems to be interrupt related because if I don't activate the TMR1 interrupt the dsPIC is not reseted. The IVT is placed at address 0x7FFFFA as supposed to. The ISR is called upon timer timeout. The weirdess thing is that if I put a breakpoint at T1Interrput() call in ISR below, the code halts every time when breakpoint is hit and when I restart execution I don't get a reset...
 
void __attribute__((__interrupt__, no_auto_psv)) _DefaultInterrupt(void)
{
    switch(INTTREGbits.VECNUM)
    {
        case 0x0B:
            T1Interrupt();     <--- Breakpoint here
            break;

        default: /* Unknown interrupt */
            Nop();
            break;
    }
}

 
Another weird thing is that if I put a breakpoint in the while loop below, the dsPIC halts when breakpoint is hit by when I restart execution, it resets.
 
int main(void)
{
    uint16_t u16Count;
// int16_t s16CurrentIpl;

    INTCON1bits.NSTDIS = 1; /* Disable interrupt nesting */
    RCONbits.SWDTEN = 0; /* Disable watchdog timer */
    CORCONbits.VAR = 0; /* Fixed exception processing is enabled */

    InitializeSystemClock(); /* Initialize system clock */

    /* Disable all modules */
    PMD1 = 0xFFFF;
    PMD2 = 0xFFFF;
    PMD3 = 0xFFFF;
    PMD4 = 0xFFFF;
    PMD6 = 0xFFFF;
    PMD7 = 0xFFFF;

    InitTmr1(); /* Start Timer 1 */

    while(1)
    {
        //DisableAllInterrupts(s16CurrentIpl);
        for(u16Count = 0U; u16Count < 100; u16Count++);
        //EnableAllInterrupts(s16CurrentIpl);
        for(u16Count = 0U; u16Count < 1000; u16Count++); <--- Breakpoint here
    };

    /* Should never reach here!!! */
    return (EXIT_SUCCESS);
}

 
Has anyone ever seen something like this !? I need help to understand and fix this problem because is its a pain in the ... to debug like this.
 
Thanks!
 
#1
T Yorky
Super (Thick) Member
  • Total Posts : 526
  • Reward points : 0
  • Joined: 2012/08/28 02:07:35
  • Location: UK
  • Status: offline
Re: dsPIC33EP512MU814 resets when debugging code in auxiliary flash 2019/10/11 05:05:52 (permalink)
0
Saw your post on the dsPIC33EP512MU814. Not used this, but used the EP256MU256 a lot (same family). It is an oddball that works different to some other PIC designs. When executing code in the 'additional aux flash' it uses a different interrupt method. See the data sheet and ref manuals. Also, even though it could have been an excellent MCU when introduced, it has a fundamental flaw that has never been corrected. Even though the boot flash and special features are provided, you can not security lock it. As it will not boot properly. See errata. This comment just from memory suggest you double check with your data sheet/errata.
#2
hbouchard
New Member
  • Total Posts : 8
  • Reward points : 0
  • Status: offline
Re: dsPIC33EP512MU814 resets when debugging code in auxiliary flash 2019/10/16 08:15:20 (permalink)
0
Hi T Yorky,
 
Unfortunatly it is too late to change... I read the errata sheet many times but this is not mentionned. I managed to debug like this but it wasn't easy. The software works it's just that I can put one breakpoint, do a step by step and that's it.
 
I agree with you, dsPIC with auxiliary memory should not be chosen for new projects. Good old dsPIC with an AIVT are much better.
 
Hugio
#3
T Yorky
Super (Thick) Member
  • Total Posts : 526
  • Reward points : 0
  • Joined: 2012/08/28 02:07:35
  • Location: UK
  • Status: offline
Re: dsPIC33EP512MU814 resets when debugging code in auxiliary flash 2019/10/16 10:11:59 (permalink)
0
Did you change your post?
Just looking at your linker script, I see you have tricked the compiler into using the AIVT as the IVT by redefining it.
For some reason you have used USB1 interrupt. But you have elected to define the default interrupt for your use. You may find the debugger intercepts this vector to detect cock-ups.
Use a different vector name.
Also look into the EP protection Errata item 31.
#4
hbouchard
New Member
  • Total Posts : 8
  • Reward points : 0
  • Status: offline
Re: dsPIC33EP512MU814 resets when debugging code in auxiliary flash 2019/10/17 02:09:10 (permalink)
0
Hi T Yorky,
 
No I didn't change my post. I use auxiliary memory IVT for bootloader. The USB1 interrupt line is commented out. I use _DefaultInterrupt as the single interrupt vector possible in auxiliary flash IVT therefore whatever interrutp is triggered, this function is called which dispatch to the right ISR (timer 1 in my case).
 
I did declared the main IVT in my linker script as well for debug purpose because if an address error trap is triggered, it vectors to the address error trap vector located at address 0x000006, in the General Segment (see Errata item 32). From the main IVT I dispatch all traps and Timer1 interrupt to my _DefaultInterrupt ISR. As I said, this is only for debug purpose.
 
I did look at Errata item 31 but code protection is not enabled at all.
 
My bootloader works, It receives a new application from CAN and writes it into General Segment as expected. It's just hard to debug as described in my first post...
 
Thanks
Hugo
#5
T Yorky
Super (Thick) Member
  • Total Posts : 526
  • Reward points : 0
  • Joined: 2012/08/28 02:07:35
  • Location: UK
  • Status: offline
Re: dsPIC33EP512MU814 resets when debugging code in auxiliary flash 2019/10/17 05:06:22 (permalink)
0
Didn't notice the comment delimiters. You can define your own vector name here. The debugger is not 100% transparent to the code and does need resources. Some memory is allocated. You will find all your data addresses 'shuffled' to accomodate this in debug. You haven't used any absolute addresses? Corrupting the debug memory area? Also (not 100% sure) the vector area has a software vector which could be used in debug, this would cause the debugger to go to the single vector. Just a note. Looked into this bootloader method and chose to use normal 'reserved area' method. The EP locks the bottom page in security mode so Aux method has no benefits. Due to MChip not correcting the faults in this chip and appear to no longer use this method, could be it is simply 'broken'. 'No Workaround' !! For general debugging look into a RTDM type of debug stub. Useful for when the chip can not be halted... USB, Bootloaders, PWM power inverters, etc...
#6
hbouchard
New Member
  • Total Posts : 8
  • Reward points : 0
  • Status: offline
Re: dsPIC33EP512MU814 resets when debugging code in auxiliary flash 2019/10/17 06:18:12 (permalink)
0
I put the bootloader in auxiliary flash because I though that IVT of auxiliary flash works like a normal AIVT available on other devices. I realized that it doesn't and it's not possbile (which is a shame) to switch between auxiliary flash IVT and general segment IVT... So I will completly forget about auxiliary flash.
 
Thanks for the RTDM debug tips. I looked into it on Microchip website and seems that it could be useful for another app I'm working on.
 
Thanks!
Hugo
#7
T Yorky
Super (Thick) Member
  • Total Posts : 526
  • Reward points : 0
  • Joined: 2012/08/28 02:07:35
  • Location: UK
  • Status: offline
Re: dsPIC33EP512MU814 resets when debugging code in auxiliary flash 2019/10/18 03:18:42 (permalink)
0
Thank you for the 'Thank you'.
 
#8
Jump to:
© 2019 APG vNext Commercial Version 4.5