• AVR Freaks

Hot!PIC32 setting breakpoints at runtime issue

Author
Luca Pascarella
Junior Member
  • Total Posts : 105
  • Reward points : 0
  • Joined: 2007/05/28 00:53:17
  • Location: The Netherlands
  • Status: offline
2020/08/04 22:41:33 (permalink)
0

PIC32 setting breakpoints at runtime issue

I'm experiencing a weird problem while adding a breakpoint at run time. This action unexpectedly generates a DHCP_EVENT_CONN_LOST event just a second before the breakpoint takes place.
 
I always paused or added a breakpoint at runtime, therefore, I suppose that PIC32 allows setting breakpoints at run time without interfering with running code. Is this true?
 
More details. I am debugging a PIC32MZ2048EFM064 connected to a LAN8740 that runs Harmony 3. It includes FreeRTOS, core 3.7.2, and net 3.6.1. Of course, the IDE is MPLAB-X 5.40 and the debugger is a Real ICE.
The unexpected behaviour occurs after the DHCP module receives a valid IP and does not depend on how long it is running.
For example, the PIC32 at startup receives a valid IP, the web pages start to work regularly, then, adding a breakpoint in any point the console reports a DHCP_EVENT_CONN_LOST and immediately after the software halts on the fresh set breakpoint.
 
Investigating the code, it seems that this event is raised by TCPIP_MAC_EV_CONN_LOST. Moreover, this flag comes from _TCPIP_ProcessTickEvent that periodically checks for links up/own. But in drv_ethmac.c I am not able to localize what causes _DRV_ETHMAC_LinkStateStartLink returning false just a moment before the breakpoint is added.
 
I appreciate any suggestions, maybe I am just missing some stupid thing here.
Thank
#1

5 Replies Related Threads

    boatbodger
    Senior Member
    • Total Posts : 126
    • Reward points : 0
    • Joined: 2011/03/27 15:39:07
    • Location: 0
    • Status: offline
    Re: PIC32 setting breakpoints at runtime issue 2020/08/05 01:08:12 (permalink)
    0
    I have found that when debugging PIC32MZ projects, it is essential to switch off all compiler optimizations.  If you don't you get weird things like this happening. 
    Also, I think there's a flag which allows you to freeze the peripherals when a breakpoint is hit - you will probably need to do that so that the Ethernet DMA does not try to continue to run while in a break point.
    I've only been using the PIC32 range for six months and it (plus Harmony) has been an extremely slow and painful learning curve, and I am nowhere near its end, yet
     
    #2
    Luca Pascarella
    Junior Member
    • Total Posts : 105
    • Reward points : 0
    • Joined: 2007/05/28 00:53:17
    • Location: The Netherlands
    • Status: offline
    Re: PIC32 setting breakpoints at runtime issue 2020/08/05 03:51:57 (permalink)
    4 (1)
    Thank for sharing your idea.
     
    I always use optimization 0 when debugging because otherwise, it is hard to follow the code flow. But just in case, I also tried with no luck -o1. So I would exclude an optimization issue.
     
    DMA Ethernet freeze seems a good point.
    I checked my settings and they are all set. I guess that a checked checkbox means to freeze the DMA when the program stops. That what I wish.
    To be sure I tried both on and off for ethernet controller freeze while debugging and the issue is still present.
     
    So far no luck.
    #3
    rainad
    Super Member
    • Total Posts : 1399
    • Reward points : 0
    • Joined: 2009/05/01 13:39:25
    • Location: 0
    • Status: offline
    Re: PIC32 setting breakpoints at runtime issue 2020/08/05 06:52:27 (permalink)
    0
    It may be that the system timer interrupt is still running when the execution is halted in the debugger.
    The stack periodically checks for the link status. If the PHY or MAC driver, upon resuming, incorrectly see that a long time has passed since it queried for the link status and there was no answer, will report an error, believing the link was down.
    Try to take a reading of the SYS_TMR_TickCountGet() before halting and immediately after resume, and check if the delay makes sense.
     
     
     
    #4
    Luca Pascarella
    Junior Member
    • Total Posts : 105
    • Reward points : 0
    • Joined: 2007/05/28 00:53:17
    • Location: The Netherlands
    • Status: offline
    Re: PIC32 setting breakpoints at runtime issue 2020/08/05 07:21:10 (permalink)
    0
    I agree I have the same suspicion that the action of adding a breakpoint in MPLAB X creates a delay in the execution that causes the software to stop for a moment. However, calling SYS_TMR_TickCountGet() before adding a breakpoint is quite hard, I do not know how to make a call at the same time I click in MLPAB X.
     
    May I was not clear enough. I am receiving the event notification at the moment that the breakpoint is added in MPLAB X even if the software does not stop on that breakpoint. Apparently the action of adding the breakpoint causes the TCPIP_MAC_EV_CONN_LOST event notification.
     
    Maybe is the RTOS causing this?
    #5
    rainad
    Super Member
    • Total Posts : 1399
    • Reward points : 0
    • Joined: 2009/05/01 13:39:25
    • Location: 0
    • Status: offline
    Re: PIC32 setting breakpoints at runtime issue 2020/08/05 08:18:30 (permalink)
    0
    OK, probably I misunderstood. If the execution does not halt, then probably the MPLAB X does something behind the scenes that upsets the execution when setting a break point. Not sure I can help with that. I myself noted for example that lengthy tests cannot be done when the debugger is connected, sooner or later the MPLAB halts the execution with no apparent reason.
     
    You can add a console command to display the current time in ms, for example.
    Call the function, set a break point, call the function again and compare the results against a reference time, maybe you spot something. But it is unlikely that the time counting will be affected if the timer interrupts are used.
     
    #6
    Jump to:
    © 2020 APG vNext Commercial Version 4.5