• AVR Freaks

Hot!Weird behaviour on dsPIC33EP512MC502

Author
mdanh2002
Starting Member
  • Total Posts : 7
  • Reward points : 0
  • Joined: 2012/05/08 22:59:59
  • Location: 0
  • Status: offline
2020/06/10 02:33:55 (permalink)
0

Weird behaviour on dsPIC33EP512MC502

Hi, 
 
I am trying to port a math library from the PIC33FJ256GP710A to the dsPIC33EP512MC502. The ported code runs well on the dsPIC33EP512MC502 simulator but returns incorrect value when running on a real device. After debugging, the issue I found is with the following lines of code:
 
    clr A
    clr B

    do   #(6-1), 2f
    mov [W2++], W5 
    mov [W3++], W6 
    mac W4*W5, A, [W8]+=2, W4
2:  mac W4*W6, B, [W8], W4
 
The above code performs some calculations and stores the final value in accumulator A and B. When the above code is run on the simulator, I receive the expected values for both accumulators and the ported code works entirely. However, when run on an actual device, value for accumulator A is correct but value for accumulator B is wrong. I have checked and confirmed that both the starting values of all required registers and the values for these registers after exiting the loop are the same on both simulator and device, just that the end result stored in accumulator B is wrong! 
 
What is weird is that if the debugger (PicKit4) is used to step through the above line of codes when running on the device, then the final value for both ACCA and ACCB will be the same as the simulator's result and therefore correct! This makes it impossible for me to use the debugger to troubleshoot the issue. What is even stranger is that simply adding NOP after each instruction in the above code will result in different final values for both ACCA and ACCB, even though the NOP is not supposed to do anything. Adding NOP when running on the simulator will not result in changes in final values of the accumulators, as expected. 
 
If I swap A and B in the last 2 lines in the above code, e.g. setting ACCB first before ACCA, then the final value of ACCB is now correct and the final value of ACCA is now wrong. This suggests that the problem might have to do with some differences in the last line of the above code, yet I cannot find out what's wrong except to suspect that there might be some timing issues. 
 
I have checked and there are no interrupt routines that could cause unexpected change of register values. Running at a much slower clock speed also does not help, so the problem is probably not electrical. 
 
Any advice is appreciated. 
post edited by mdanh2002 - 2020/06/10 05:35:59
#1

15 Replies Related Threads

    du00000001
    Just Some Member
    • Total Posts : 3942
    • Reward points : 0
    • Joined: 2016/05/03 13:52:42
    • Location: Germany
    • Status: offline
    Re: Weird behaviour on dsPIC33EP512MC502 2020/06/10 03:36:39 (permalink)
    0
    Did you sift through the Migration Guide or are you just applying the "well proven" method try and error ?
     
    The simulator is by no way an exact tool. As you already found out, debugging influences the code (execution). Which might or might not have to do with the timing.
    But the debugger is not completely useless: if instead of single-stepping you place a breakpoint behind the code in question, you can at least check the results without additional output hassle.
     
    See http://ww1.microchip.com/downloads/en/DeviceDoc/70637D.pdf 

    PEBKAC / EBKAC / POBCAK / PICNIC (eventually see en.wikipedia.org)
    #2
    Gort2015
    Klaatu Barada Nikto
    • Total Posts : 3992
    • Reward points : 0
    • Joined: 2015/04/30 10:49:57
    • Location: 0
    • Status: offline
    Re: Weird behaviour on dsPIC33EP512MC502 2020/06/10 04:00:52 (permalink)
    1 (1)
    Save A and B,     C can modify them just like any register.
    Configure Accumulators before using.
     
    Try this:
     
    void testsave (unsigned int *A, unsigned int *B);
     
    arg_A = w0
    arg_B = w1
     
    _testsave:
        clr   A
        clr   B
        do    #6-1, next
        ; - - - - - - - - - - - - - - - -
        mov   [W2++], W5 
        mov   [W3++], W6 
        mac   W4*W5, A, [W8]+=2, W4
        mac   W4*W6, B, [W8], W4
        ; - - - - - - - - - - - - - - - -
        ; - save A, B -
        sac.d A, [arg_A++]
        ; - - - - - - - - - - - - - - - -
    next:
        sac.d B, [arg_B++]
        return

    sac.d only supported on CH/CK chips.
     
    ; replace with something like:
    push ACCAL
    push ACCAH
    pop.d [arg_A++]

    MPLab X playing up, bug in your code? Nevermind, Star Trek:Discovery will be with us soon.
    https://www.youtube.com/watch?v=Iu1qa8N2ID0
    + ST:Continues, "What Ships are Made for", Q's back.
    #3
    Gort2015
    Klaatu Barada Nikto
    • Total Posts : 3992
    • Reward points : 0
    • Joined: 2015/04/30 10:49:57
    • Location: 0
    • Status: offline
    Re: Weird behaviour on dsPIC33EP512MC502 2020/06/10 04:05:27 (permalink)
    1 (1)
    Space  6 * 4 * 2 Bytes.
     

    MPLab X playing up, bug in your code? Nevermind, Star Trek:Discovery will be with us soon.
    https://www.youtube.com/watch?v=Iu1qa8N2ID0
    + ST:Continues, "What Ships are Made for", Q's back.
    #4
    mdanh2002
    Starting Member
    • Total Posts : 7
    • Reward points : 0
    • Joined: 2012/05/08 22:59:59
    • Location: 0
    • Status: offline
    Re: Weird behaviour on dsPIC33EP512MC502 2020/06/10 05:22:01 (permalink)
    0
    I did go through the migration guide and could not find anything that relates to my problem. After all, I made several changes before the code can run well on the simulator. 
     
    The issue is if a debugger breakpoint has been placed into the above loop section, then the values of ACCA and ACCB after exiting the loop will be correct, even when I don't step the code and just use Debug > Continue to run until the next breakpoint right after the loop. If the first breakpoint is placed before the above code, then the final value will be wrong (and always the same value). And why would adding NOP result in changes in final value of ACCA and ACCB, I still cannot figure it out. This is very strange. 
    post edited by mdanh2002 - 2020/06/10 05:25:07
    #5
    Gort2015
    Klaatu Barada Nikto
    • Total Posts : 3992
    • Reward points : 0
    • Joined: 2015/04/30 10:49:57
    • Location: 0
    • Status: offline
    Re: Weird behaviour on dsPIC33EP512MC502 2020/06/10 05:40:19 (permalink)
    2 (3)
    Don't rely on simulators, debuggers or MCC.
     
    Running on a real chip the nops will have no affect on A or B.
     

    MPLab X playing up, bug in your code? Nevermind, Star Trek:Discovery will be with us soon.
    https://www.youtube.com/watch?v=Iu1qa8N2ID0
    + ST:Continues, "What Ships are Made for", Q's back.
    #6
    mdanh2002
    Starting Member
    • Total Posts : 7
    • Reward points : 0
    • Joined: 2012/05/08 22:59:59
    • Location: 0
    • Status: offline
    Re: Weird behaviour on dsPIC33EP512MC502 2020/06/10 05:43:15 (permalink)
    5 (1)
    Gort2015
    Don't rely on simulators, debuggers or MCC.
     
    Running on a real chip the nops will have no affect on A or B.
     




    In my tests, adding NOPs change the value of A and B when running on the real chip. The simulator works properly as it should. Something really strange is going on.
    #7
    Gort2015
    Klaatu Barada Nikto
    • Total Posts : 3992
    • Reward points : 0
    • Joined: 2015/04/30 10:49:57
    • Location: 0
    • Status: offline
    Re: Weird behaviour on dsPIC33EP512MC502 2020/06/10 07:34:18 (permalink)
    3 (2)
    You've only shown 7 instructions that work.
    W4 set ?
     
    A lot of things can go wrong if you do not understand
    how the accumulators work.
     
    Copy A and B to the arrays so that you can print them out after.
     
    Your tests are wrong if you think that a nop can change a register.
     
    Configured for float or integer ?
    Size ?

    MPLab X playing up, bug in your code? Nevermind, Star Trek:Discovery will be with us soon.
    https://www.youtube.com/watch?v=Iu1qa8N2ID0
    + ST:Continues, "What Ships are Made for", Q's back.
    #8
    mdanh2002
    Starting Member
    • Total Posts : 7
    • Reward points : 0
    • Joined: 2012/05/08 22:59:59
    • Location: 0
    • Status: offline
    Re: Weird behaviour on dsPIC33EP512MC502 2020/06/10 08:37:59 (permalink)
    5 (2)
    I fixed the issue. The solution was mentioned in a single sentence in the migration guide which was overlooked. The first instruction right after the DO instruction on the dsPIC33E/PIC24E cannot be an instruction that accesses the PSV data space. Apparently the simulator does not care and so things work properly on the simulator. On my code, [W2++] and [W3++] point to PSV and there is the problem. Adding a single NOP right after the DO instruction and the code now works properly with same result on both device and simulator. And yes, once you violate this rule, weird things will happen, including the fact that adding NOP will result in different register values. Either that or the debugger was confused and showed wrong data. And well, the NOPs I tried to add during the debugging phase were in various places but never right after the DO instruction, otherwise I would have figured it out much sooner. Once this issue is sorted, things work as it should and adding further NOPs will not affect anything.
    post edited by mdanh2002 - 2020/06/10 08:45:11
    #9
    du00000001
    Just Some Member
    • Total Posts : 3942
    • Reward points : 0
    • Joined: 2016/05/03 13:52:42
    • Location: Germany
    • Status: offline
    Re: Weird behaviour on dsPIC33EP512MC502 2020/06/10 08:44:49 (permalink)
    5 (2)
    Incredible: it's been in the migration guide ! Smile
     
    @ Gort2015
    Sometimes even NOPs count

    PEBKAC / EBKAC / POBCAK / PICNIC (eventually see en.wikipedia.org)
    #10
    mdanh2002
    Starting Member
    • Total Posts : 7
    • Reward points : 0
    • Joined: 2012/05/08 22:59:59
    • Location: 0
    • Status: offline
    Re: Weird behaviour on dsPIC33EP512MC502 2020/06/10 08:50:24 (permalink)
    5 (1)
    If I were the developer of the assembler, I would have added a big warning or even thrown an error if a violation of that rule is detected. Granted, this might not be always easy, but in my case W2 and W3 came directly from psvoffset and the assembler could have been smart enough to warn me of this. Wasted 3 days to debug before I could isolate the problem.
    post edited by mdanh2002 - 2020/06/10 09:07:37
    #11
    Gort2015
    Klaatu Barada Nikto
    • Total Posts : 3992
    • Reward points : 0
    • Joined: 2015/04/30 10:49:57
    • Location: 0
    • Status: offline
    Re: Weird behaviour on dsPIC33EP512MC502 2020/06/10 09:00:44 (permalink)
    2 (2)
    In this case though, nops do not count.
    You said compiler, do you mean Assembler ?
     
    Inline ?
     
    Assemblers don't know about run-time
    but if you try and assemble this:
     
    do #10, x
    nop
    x: nop
    bra $+4
    nop
     
    "bra" - assembler can spot that.
     
     
     
     
     
     

    MPLab X playing up, bug in your code? Nevermind, Star Trek:Discovery will be with us soon.
    https://www.youtube.com/watch?v=Iu1qa8N2ID0
    + ST:Continues, "What Ships are Made for", Q's back.
    #12
    mdanh2002
    Starting Member
    • Total Posts : 7
    • Reward points : 0
    • Joined: 2012/05/08 22:59:59
    • Location: 0
    • Status: offline
    Re: Weird behaviour on dsPIC33EP512MC502 2020/06/10 09:05:49 (permalink)
    0
    Yes, I meant the assembler. It could have been smarter.
    post edited by mdanh2002 - 2020/06/10 09:06:56
    #13
    Gort2015
    Klaatu Barada Nikto
    • Total Posts : 3992
    • Reward points : 0
    • Joined: 2015/04/30 10:49:57
    • Location: 0
    • Status: offline
    Re: Weird behaviour on dsPIC33EP512MC502 2020/06/10 09:19:26 (permalink)
    2 (2)
    Runtime code though, how do you think it would be possible?
     
    Assemblers don't need to be smart, that would mean injecting
    additional code into your program.

    MPLab X playing up, bug in your code? Nevermind, Star Trek:Discovery will be with us soon.
    https://www.youtube.com/watch?v=Iu1qa8N2ID0
    + ST:Continues, "What Ships are Made for", Q's back.
    #14
    du00000001
    Just Some Member
    • Total Posts : 3942
    • Reward points : 0
    • Joined: 2016/05/03 13:52:42
    • Location: Germany
    • Status: offline
    Re: Weird behaviour on dsPIC33EP512MC502 2020/06/10 09:20:54 (permalink)
    2 (1)
    I wish I could just drop-in a concept, getting great code generated automatically  Smile
    So many wishes remaining unfulfilled...

    PEBKAC / EBKAC / POBCAK / PICNIC (eventually see en.wikipedia.org)
    #15
    Gort2015
    Klaatu Barada Nikto
    • Total Posts : 3992
    • Reward points : 0
    • Joined: 2015/04/30 10:49:57
    • Location: 0
    • Status: offline
    Re: Weird behaviour on dsPIC33EP512MC502 2020/06/10 09:36:25 (permalink)
    1 (1)
    You could write faster C by getting it close to
    the machine level.
    Remove all while, for, do control loops
    and replace with goto's and break down
    any math into single parts.
     
    You lose top-down coding.
    It won't look good either but it be faster.
     
    All the goto's get replaced by relative branches.

    MPLab X playing up, bug in your code? Nevermind, Star Trek:Discovery will be with us soon.
    https://www.youtube.com/watch?v=Iu1qa8N2ID0
    + ST:Continues, "What Ships are Made for", Q's back.
    #16
    Jump to:
    © 2020 APG vNext Commercial Version 4.5