• AVR Freaks

Hot!Issue with entire dsPIC33Cx family with byte mode instructions? - resolved

Page: 1234 > Showing page 1 of 4
Author
JimDrew
Super Member
  • Total Posts : 342
  • Reward points : 0
  • Joined: 2003/11/07 12:37:26
  • Status: offline
2019/03/05 00:06:41 (permalink)
4 (1)

Issue with entire dsPIC33Cx family with byte mode instructions? - resolved

Did anyone else catch this note in the errata for every dsPIC33CK and dsPIC33CH part?
 
"When using Byte mode instructions, the upper byte of the destination register may not be persistent."
 
I asked Microchip for a clarification on exactly what this means a week ago.  I have heard nothing yet.
 
This seems to indicate that writing .b might kill the upper byte of the word in the destination.  Has anyone ran into any issues with byte mode instructions?
 
post edited by JimDrew - 2019/03/22 00:50:21
#1

71 Replies Related Threads

    Aussie Susan
    Super Member
    • Total Posts : 3608
    • Reward points : 0
    • Joined: 2008/08/18 22:20:40
    • Location: Melbourne, Australia
    • Status: offline
    Re: Issue with entire dsPIC33Cx family with byte mode instructions? 2019/03/05 18:51:12 (permalink)
    0
    Ouch - that could be nasty!
    Susan
    #2
    Stampede
    Super Member
    • Total Posts : 400
    • Reward points : 0
    • Joined: 2006/10/04 05:59:28
    • Location: Germany
    • Status: offline
    Re: Issue with entire dsPIC33Cx family with byte mode instructions? 2019/03/06 01:43:13 (permalink)
    0
    I agree, that a weird error, and sorry no experience on that. Using the parts with the XC16 and only the 3P3Z assembly routines by microchip, and they don't use those instructions. So i assume (but I guess you need to double check) that XC16 won't use any of the below mentioned instructions.
     
    If we look at other erratas, I'm really wondering how you would "create" those... keeping in mind that the dspic33EP e.g. uses the same core afaic., and they don't have them. Maybe someone with more experience in semiconductor design may enlighten me....
     
    dsPIC33CH512MP508, all CPU errata are marked without work around:
    #15 CPU: The FLIM instruction may incorrectly limit the data range...
    #16 CPU: ...the output for MAXAB, MINAB and MINZAB instructions may be incorrect...
    #17 CPU: When using the Signed 32-by-16-Bit Division instruction, div.sd, the Overflow bit may not always get...
    #18 CPU: When using Byte mode instructions, the upper byte of the destination register may not be persistent.
     
    #3
    MBedder
    Circuit breaker
    • Total Posts : 6773
    • Reward points : 0
    • Joined: 2008/05/30 11:24:01
    • Location: Zelenograd, Russia
    • Status: offline
    Re: Issue with entire dsPIC33Cx family with byte mode instructions? 2019/03/06 02:18:16 (permalink)
    0
    Stampede...keeping in mind that the dspic33EP e.g. uses the same core
    No. The Cx core(s) are completely different. And all the Cx are too new to make a practical use of them.


    #4
    Gort2015
    Klaatu Barada Nikto
    • Total Posts : 3146
    • Reward points : 0
    • Joined: 2015/04/30 10:49:57
    • Location: 0
    • Status: offline
    Re: Issue with entire dsPIC33Cx family with byte mode instructions? 2019/03/06 03:10:47 (permalink)
    0
    I have tested and use the new instructions including, "flim".
    Part1:
    ;----------------------------------------------------
    ;----------------------------------------------------
    ;----------------------------------------------------
    .equ arg_Text,      w0
    .equ txt,           w0  ;psuedym
    .equ txtlen,        w1
    .equ maxalpha_l,    w2
    .equ minalpha_l,    w3
    .equ maxdec,        w4
    .equ mindec,        w5
    .equ maxalpha_h,    w6
    .equ minalpha_h,    w7
    .equ TXT,           w8  ;global
    .equ _PC,           w9  ;global
    .equ tmp,          w10
    .equ SP,           w15
    ;rtn txt,           w0
    ;rtn txtlen,        w1
    ;rtn valid,          Z

    symbol_valid:
        push    w10
        mov     #'0',mindec
        mov     #'9',maxdec
        mov     #'A',minalpha_h
        mov     #'Z',maxalpha_h
        mov     #'a',minalpha_l
        mov     #'z',maxalpha_l
        setm    txtlen
        bclr    WS2412B_Flag,#WSFLAG_ALPHA
        bra     $+4
        ;~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    looptxtlensp:
        ;ready for next entry
        dec2    SP,SP       ;clear flim stack
        ;~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    looptxtlen:
        ;get char, ascii 'A' - 'Z', '0' - '9' or underscore
        inc     txtlen,txtlen
        ze      [txt++],tmp
        ;~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
        ;underscore ok
        cp      tmp,#'_'
        bra     z,looptxtlen
        ;~~~~~~~~~~~~~~~~~~~~~~~~~~~~~


    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.
    #5
    Gort2015
    Klaatu Barada Nikto
    • Total Posts : 3146
    • Reward points : 0
    • Joined: 2015/04/30 10:49:57
    • Location: 0
    • Status: offline
    Re: Issue with entire dsPIC33Cx family with byte mode instructions? 2019/03/06 03:11:53 (permalink)
    0
    Part2:
        ;decimal and alpha was first?
        push    tmp
        flim    maxdec,tmp
        bra     nz,tryupper
        btss    WS2412B_Flag,#WSFLAG_ALPHA
        bra     err_syntaxsp
        bra     looptxtlensp
        ;~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    tryupper:
        ;uppercase?
        mov     [SP-2],tmp
        flim    maxalpha_h,tmp
        bra     nz,trylower
        bset    WS2412B_Flag,#WSFLAG_ALPHA
        bra     looptxtlensp
        ;~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    trylower:
        ;lowercase?
        flim    maxalpha_l,[--SP]
        bra     nz,$+6
        bset    WS2412B_Flag,#WSFLAG_ALPHA
        bra     looptxtlen
        ;~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
        ;found symbol, at least one alpha?
        btss    WS2412B_Flag,#WSFLAG_ALPHA
        bra     err_syntax
        ;~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
        ;back 1
        dec     txt,txt
        ;~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
        ;success, w0 = txt, w1 = txtlen
        pop     w10
        bset    SR,#Z
        return
        ;~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    err_syntaxsp:
        dec2    SP,SP   ;clear tmp
        ;~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    err_syntax:
        dec2    SP,SP   ;clr flag
        ;~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    err_syntaxspclr:
        pop     w10
        bclr    SR,#Z
        return
    ;----------------------------------------------------
    ;----------------------------------------------------
    ;----------------------------------------------------

     

    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
    Gort2015
    Klaatu Barada Nikto
    • Total Posts : 3146
    • Reward points : 0
    • Joined: 2015/04/30 10:49:57
    • Location: 0
    • Status: offline
    Re: Issue with entire dsPIC33Cx family with byte mode instructions? 2019/03/06 03:13:18 (permalink)
    0
    I had a problem displaying code with this forum software but changing the font seems to fix 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.
    #7
    MBedder
    Circuit breaker
    • Total Posts : 6773
    • Reward points : 0
    • Joined: 2008/05/30 11:24:01
    • Location: Zelenograd, Russia
    • Status: offline
    Re: Issue with entire dsPIC33Cx family with byte mode instructions? 2019/03/06 03:55:41 (permalink)
    0
    So what is your conclusion after you have tested that?
    #8
    Gort2015
    Klaatu Barada Nikto
    • Total Posts : 3146
    • Reward points : 0
    • Joined: 2015/04/30 10:49:57
    • Location: 0
    • Status: offline
    Re: Issue with entire dsPIC33Cx family with byte mode instructions? 2019/03/06 04:44:53 (permalink)
    0
    My conclusion would be to test each new instruction yourself instead of moaning.
    Check all source and destination operands directly and indirectly.
     
    I really like the instruction set, it's easy to work with.
     
     
    As for that high byte changing when writing the low byte, that would make the whole chip useless.
     
     
    I was using a chip a while back and the errata said that the EXCH instruction did not work but it did.
     
    That code is not test code, it is from an assembler.

    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.
    #9
    Gort2015
    Klaatu Barada Nikto
    • Total Posts : 3146
    • Reward points : 0
    • Joined: 2015/04/30 10:49:57
    • Location: 0
    • Status: offline
    Re: Issue with entire dsPIC33Cx family with byte mode instructions? 2019/03/06 05:01:41 (permalink)
    0
    Be carefull when trying to pass a flag as an argument to a function.
    i.e.
    bset SR,#Z
    rcall somefunc   <-- will not work with E, CH and CK chips since RCALL clears the SFA.
    call somefunc   <-- will not work with E, CH and CK chips since CALL clears the SFA.
     
    My code was not working but after checking the programmers guide, I discovered why.
    This worked on previous series chips, I don't know why they had to change it.  It's not a bug but would make code written for previous generation chips fail.
     

    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.
    #10
    NorthGuy
    Super Member
    • Total Posts : 5543
    • Reward points : 0
    • Joined: 2014/02/23 14:23:23
    • Location: Northern Canada
    • Status: offline
    Re: Issue with entire dsPIC33Cx family with byte mode instructions? 2019/03/06 07:24:37 (permalink)
    5 (1)
    Gort2015
    My conclusion would be to test each new instruction yourself instead of moaning.



    You can't. It may work for some temperatures, voltages, on some chips, but not work on others at different temperatures, different voltages etc. Even if you test it on 100 samples over all the conditions (which is a tremendous task), there's no guarantee that the your tests apply to a different batch, because you don't really have any information on how they're manufactured.
    #11
    Gort2015
    Klaatu Barada Nikto
    • Total Posts : 3146
    • Reward points : 0
    • Joined: 2015/04/30 10:49:57
    • Location: 0
    • Status: offline
    Re: Issue with entire dsPIC33Cx family with byte mode instructions? 2019/03/06 07:32:20 (permalink)
    0
    That is a good point.
    Usually the errata document has work arounds.
     
    Did anyone get any info on the un-released 16bit RA chips?

    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
    JPortici
    Super Member
    • Total Posts : 706
    • Reward points : 0
    • Joined: 2012/11/17 06:27:45
    • Location: Grappaland
    • Status: offline
    Re: Issue with entire dsPIC33Cx family with byte mode instructions? 2019/03/06 23:35:01 (permalink)
    0
    I wish. still no info on the XC16 V1.36
    #13
    JimDrew
    Super Member
    • Total Posts : 342
    • Reward points : 0
    • Joined: 2003/11/07 12:37:26
    • Status: offline
    Re: Issue with entire dsPIC33Cx family with byte mode instructions? 2019/03/07 00:59:53 (permalink)
    0
    I am a little concerned since I write strictly in assembly and I do a LOT of byte operations on data streams and tables.  I have not seen anything odd yet when moving PIC24 and dsPIC33EP code over, but it seems strange to me that there would be this errata if some type of problem did not exist!  You can't do a mov [xx],yy on an odd address and there are cases where you may not immediately know if the address is odd or even.  I would hate to have to test the address and have separate routines for a simple mov.b [xx],yy.
     
    I am still waiting for a response from Microchip on this.
    #14
    JimDrew
    Super Member
    • Total Posts : 342
    • Reward points : 0
    • Joined: 2003/11/07 12:37:26
    • Status: offline
    Re: Issue with entire dsPIC33Cx family with byte mode instructions? 2019/03/12 22:02:59 (permalink)
    4.33 (3)
    Well... got a preliminary answer from Microchip today.  Apparently there is a bug in the silicon that affects every single CK and CH chip model.  In short, any instruction used in byte mode (.b) can destroy the upper byte.
     
    I asked for clarification if this really means both register and memory operations.
     
    I gave an example, and was told to avoid any byte operation:
     
    mov.b w0,w1
    sl w1,#8,w1
    mov.b w2,w1
     
    Apparently the first and last instructions can affect the upper byte of w1.
     
    This is an absolute show stopper to me.  I parse buffers using byte operations (like mov.b [w2++],w0), expecting the upper byte of w0 to be unaffected:
     
    mov.b [w2++],w0  ; get servo position high byte from buffer
    sl w0,#8,w0    ; move to upper byte of word
    mov.b [w2++],w0  ; get servo position low byte from buffer
     
    Since I am never guaranteed that the buffer will be on an even address (and it's typically not) I can't simply load a word because that causes a CPU odd address fault.
     
    The only way I can see to handle things like this is to add extra code to AND and OR at a word level:
     
    mov.b [w2++],w0  ; get servo position high byte from buffer
    sl w0,#8,w0   ; move to upper byte of word
    mov.b [w2++],w1  ; get servo position low byte from buffer
    and #0x00FF,w1  ; kill upper byte
    or w0,w1,w0  ; OR upper/lower together
     
    This is a valid work-around, but the problem for me with this is that it adds 2 extra cycles time every time through a loop and requires an extra register.  I am cycle counting everything and this would mean re-writing all of this code which has been working for years without change.  It would also require a significant round of costly re-testing/re-qualifying to do this.
     
    So... I have written a bunch of test code and I have not been able to duplicate whatever it is that caused the errata to have been written.  I am hoping that Microchip will let me know tomorrow the exact circumstances required to cause this issue.
     
    #15
    MBedder
    Circuit breaker
    • Total Posts : 6773
    • Reward points : 0
    • Joined: 2008/05/30 11:24:01
    • Location: Zelenograd, Russia
    • Status: offline
    Re: Issue with entire dsPIC33Cx family with byte mode instructions? 2019/03/13 01:26:39 (permalink)
    0
    Holy... chip! sad
    #16
    Howard Long
    Super Member
    • Total Posts : 676
    • Reward points : 0
    • Joined: 2005/04/04 08:50:32
    • Status: offline
    Re: Issue with entire dsPIC33Cx family with byte mode instructions? 2019/03/13 03:35:40 (permalink)
    0
    JimDrew
    Well... got a preliminary answer from Microchip today.  Apparently there is a bug in the silicon that affects every single CK and CH chip model.  In short, any instruction used in byte mode (.b) can destroy the upper byte.
     
    I asked for clarification if this really means both register and memory operations.
     
    I gave an example, and was told to avoid any byte operation:
     
    mov.b w0,w1
    sl w1,#8,w1
    mov.b w2,w1
     
    Apparently the first and last instructions can affect the upper byte of w1.



    I may have missed it, but has anyone been able to reproduce and demonstrate this fault yet?
     
    I also note that the fault only seems to be documented in the errata for CK and newer high memory CH devices. The original CH devices' errata either haven't been updated, or perhaps these are immune (against JimDrew's Microchip communication).
     
    Knowing the criteria for the fault to disclose itself seems key to be able to make a decision on this.
    post edited by Howard Long - 2019/03/13 03:56:17
    #17
    JimDrew
    Super Member
    • Total Posts : 342
    • Reward points : 0
    • Joined: 2003/11/07 12:37:26
    • Status: offline
    Re: Issue with entire dsPIC33Cx family with byte mode instructions? 2019/03/13 20:52:54 (permalink)
    5 (1)
    I hadn't noticed that the original (lower memory) parts didn't have this notice in the errata.  I was just told to not use byte operations on any of the CK/CH parts.  I will also get that clarified.
     
    I can't reproduce this, but I have not written a complete test suite to try.  I also have not seen any issues with our product (thankfully not in production yet) over a few months of testing.
     
    We definitely need to know the exact condition(s) where this issue actually occurs.
     
     
    post edited by JimDrew - 2019/03/13 20:54:25
    #18
    Gort2015
    Klaatu Barada Nikto
    • Total Posts : 3146
    • Reward points : 0
    • Joined: 2015/04/30 10:49:57
    • Location: 0
    • Status: offline
    Re: Issue with entire dsPIC33Cx family with byte mode instructions? 2019/03/14 06:11:33 (permalink)
    0
    mov.b w0,w1
    sl w1,#8,w1
    mov.b w2,w1
    "Apparently the first and last instructions can affect the upper byte of w1".
     
    LOL
     
     

    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.
    #19
    Gort2015
    Klaatu Barada Nikto
    • Total Posts : 3146
    • Reward points : 0
    • Joined: 2015/04/30 10:49:57
    • Location: 0
    • Status: offline
    Re: Issue with entire dsPIC33Cx family with byte mode instructions? 2019/03/14 06:26:24 (permalink)
    0
    You were told by some random person to avoid byte operations on a chip designed to perform byte operations.
     

    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.
    #20
    Page: 1234 > Showing page 1 of 4
    Jump to:
    © 2019 APG vNext Commercial Version 4.5