Hot!First byte of array overwritten

Page: 12 > Showing page 1 of 2
Author
JBecker32
Starting Member
  • Total Posts : 39
  • Reward points : 0
  • Joined: 2012/12/17 02:30:04
  • Location: 0
  • Status: offline
2018/05/01 05:09:16 (permalink)
0

First byte of array overwritten

Hi,
I have a strange problem when moving from V1.33 compiler (where I have a full license but aspic18 problems) to V1.45.
I have transmit and receive buffers defined for the UART2 (PIC18F45K80). Depending on the sizes defined, either Rx2Buffer or Tx2Buffer starts in memory at address 0x60. When running the program, always the first byte (at 0x60) is overwritten with 0 after returning from the ISR (as far as I can see). I made a lot of tests and found that I can stop this by introducing some dummy variables. I have no idea where variable 'btemp' comes from, I do not have it in the sources anywhere. But it depends on how many bytes lie between 'btemp' and the buffer start at 0x60. If its is three bytes, the code works. If it is only one or two bytes, 0x60 is overwritten.
Does anybody have a clue?
 
BR, Jörg.
 

Attached Image(s)

#1

35 Replies Related Threads

    du00000001
    Just Some Member
    • Total Posts : 2132
    • Reward points : 0
    • Joined: 2016/05/03 13:52:42
    • Location: Germany
    • Status: offline
    Re: First byte of array overwritten 2018/05/01 05:55:59 (permalink)
    +1 (1)
    Provided you use the compiled stack model, btemp might be created as some substitute for aa auto ("stack") variable.
    The map file might (or might not) tell you from where this variable is refernced. Otherwise you might be able to set a data breakpoint to this variable (depends on HW features available).

    PEBKAC / EBKAC / POBCAK / PICNIC (eventually see en.wikipedia.org)
    #2
    NKurzman
    A Guy on the Net
    • Total Posts : 16446
    • Reward points : 0
    • Joined: 2008/01/16 19:33:48
    • Location: 0
    • Status: offline
    Re: First byte of array overwritten 2018/05/01 06:03:04 (permalink)
    +1 (1)
    How are these defined? What is happening in the interrupt?
    #3
    JBecker32
    Starting Member
    • Total Posts : 39
    • Reward points : 0
    • Joined: 2012/12/17 02:30:04
    • Location: 0
    • Status: offline
    Re: First byte of array overwritten 2018/05/01 06:10:25 (permalink)
    0
    In the .map file I find the following in the symbol table:

    btemp     temp  00005D
    ....
    int$flags temp  00005D
     
    ....
     
    [font="%value"]What does 'int$flags' mean? But even if this resides at 0x5D, why is 0x60 overwritten with zero?

     

    #4
    qɥb
    Monolothic Member
    • Total Posts : 3329
    • Reward points : 0
    • Joined: 2017/09/09 05:07:30
    • Location: Jupiter
    • Status: offline
    Re: First byte of array overwritten 2018/05/01 06:11:34 (permalink)
    +4 (4)
    the bug is hidden somewhere in the code you have not shown us...
     

    This forum is mis-configured so it only works correctly if you access it via https protocol.
    The Microchip website links to it using http protocol. Will they ever catch on?
    PicForum "it just works"
    #5
    du00000001
    Just Some Member
    • Total Posts : 2132
    • Reward points : 0
    • Joined: 2016/05/03 13:52:42
    • Location: Germany
    • Status: offline
    Re: First byte of array overwritten 2018/05/01 06:19:03 (permalink)
    +1 (1)
    Any variable called "flags" in some ISR code? M8ght be an int.
    (As 5E and 5F carry some values: break, initialize these (e.g. with zero) and reset - just to see that these get overwritten.
    Further refinement of breaking might bring you closer to the "impact area".
    (3 bytes affected lookslike some "abuse" for a 24-Bit float variable.)
     

    PEBKAC / EBKAC / POBCAK / PICNIC (eventually see en.wikipedia.org)
    #6
    JBecker32
    Starting Member
    • Total Posts : 39
    • Reward points : 0
    • Joined: 2012/12/17 02:30:04
    • Location: 0
    • Status: offline
    Re: First byte of array overwritten 2018/05/01 06:22:38 (permalink)
    0
    NKurzman
    How are these defined? What is happening in the interrupt?

    #define RX2BUFSIZE 32
    uint8_t Rx2Buffer[RX2BUFSIZE];
     
    I think I cannot post the whole code. But there is a state machine in the ISR, where one received byte after the other is stored in Rx2Buffer. After storing the first byte in Rx2Buffer[0], I can se it there. But this location is cleared after returning from the ISR to the main code. All the other bytes are stored without problems. 
    Same happens if I set the Tx2Buffer to a bigger size. It is then located at 0x60 (instead of Rx2Buffer). And here the same happens. I store one byte in Tx2Buffer, then the TX interrupt fires and when entering the TX ISR, the first buffer location is empty. 
     
     
    qɥb
    the bug is hidden somewhere in the code you have not shown us...

    Possibly yes. But the same code runs without problems when compiled with V1.33 to V1.38. And it runs if I introduce dummy variables (see first post).
     
     
    #7
    JBecker32
    Starting Member
    • Total Posts : 39
    • Reward points : 0
    • Joined: 2012/12/17 02:30:04
    • Location: 0
    • Status: offline
    Re: First byte of array overwritten 2018/05/01 06:29:27 (permalink)
    0
    du00000001
    Any variable called "flags" in some ISR code? M8ght be an int.
    (As 5E and 5F carry some values: break, initialize these (e.g. with zero) and reset - just to see that these get overwritten.
    Further refinement of breaking might bring you closer to the "impact area".
    (3 bytes affected lookslike some "abuse" for a 24-Bit float variable.)
     

     
    If I clear memory locations 0x5E and 0x5F, they are changed to other values again.
    A variable called 'Flags' is used in the CAN interrupt routine. Hmmm, why should the compiler/linker place it here so that it overwrites the arrays? And, no, it is placed in a different RAM area.
    I do not use floats (never). 
     
    #8
    du00000001
    Just Some Member
    • Total Posts : 2132
    • Reward points : 0
    • Joined: 2016/05/03 13:52:42
    • Location: Germany
    • Status: offline
    Re: First byte of array overwritten 2018/05/01 07:20:11 (permalink)
    0
    Seems btemp is used for variables exceeding its declared size.
    What about pointers "running wild"?
    Maybe it helps to set the warning level as low as possible anf fork through all the warnings thrown...

    PEBKAC / EBKAC / POBCAK / PICNIC (eventually see en.wikipedia.org)
    #9
    JBecker32
    Starting Member
    • Total Posts : 39
    • Reward points : 0
    • Joined: 2012/12/17 02:30:04
    • Location: 0
    • Status: offline
    Re: First byte of array overwritten 2018/05/01 07:47:14 (permalink)
    0
    I am seeing something now, but I do not yet understand it .....
     
    If I switch the view to 'Disassembly' and single-step through the code, after returning from the high_isr ISR, there is a statement:
    0xD0A: MOVFF 0x40, Rx2Buffer
    and this clears the first location of Rx2Buffer.
    But I do not see where this code comes from ....???
     
    ! if( PIR3bits.CCP2IF ) // Timer1 compare interrupt
    0xCF8: BTFSS PIR3, 2, ACCESS
    ! {
    ! _AUX2_ON;
    ! PIR3bits.CCP2IF = 0;
    0xCFC: BCF PIR3, 2, ACCESS
    ! PIE3bits.CCP2IE = 1;
    0xCFE: BSF PIE3, 2, ACCESS
    ! IntRunning = 0x01; // for watchdog
    0xD00: MOVLW 0x1
    ! DoEvery_ms(); // 1ms tasks
    0xD06: CALL 0x13B6, 0
    ! _AUX2_OFF;
    ! }
    !}
    0xD0A: MOVFF 0x40, Rx2Buffer
    !void DoEvery_ms(void)
    !{
    ! static uint8_t _1msCnt;
    ! Blink_5s++;
    0x13B6: INCF Blink_5s, F, ACCESS
    !
     
    This code is located after the closing bracket of the high_isr ISR. 
     
     
     
    #10
    JBecker32
    Starting Member
    • Total Posts : 39
    • Reward points : 0
    • Joined: 2012/12/17 02:30:04
    • Location: 0
    • Status: offline
    Re: First byte of array overwritten 2018/05/01 07:50:45 (permalink)
    0
    In the .lst file I see the following:
     
    4141 000D0A C041 F060 movff ??_high_isr+17,btemp+3
    4142 000D0E C040 F05F movff ??_high_isr+16,btemp+2
    4143 000D12 C03F F05E movff ??_high_isr+15,btemp+1
    4144 000D16 C03E F05D movff ??_high_isr+14,btemp
    4145 000D1A C03D FFF5 movff ??_high_isr+13,tablat
    4146 000D1E C03C FFF8 movff ??_high_isr+12,tblptru
    4147 000D22 C03B FFF7 movff ??_high_isr+11,tblptrh
    4148 000D26 C03A FFF6 movff ??_high_isr+10,tblptrl
    4149 000D2A C039 FFF4 movff ??_high_isr+9,prodh
    4150 000D2E C038 FFF3 movff ??_high_isr+8,prodl
    4151 000D32 C037 FFDA movff ??_high_isr+7,fsr2h
    4152 000D36 C036 FFD9 movff ??_high_isr+6,fsr2l
    4153 000D3A C035 FFE2 movff ??_high_isr+5,fsr1h
    4154 000D3E C034 FFE1 movff ??_high_isr+4,fsr1l
    4155 000D42 C033 FFEA movff ??_high_isr+3,fsr0h
    4156 000D46 C032 FFE9 movff ??_high_isr+2,fsr0l
    4157 000D4A C031 FFFB movff ??_high_isr+1,pclatu
    4158 000D4E C030 FFFA movff ??_high_isr,pclath
    4159 000D52 925D bcf btemp,1,c ;clear compiler interrupt flag (level 2)
    4160 000D54 0011 retfie f
    4161 000D56 __end_of_high_isr:
     
    seems that btemp is a long and this would explain why the buffer is overwritten if there is less than 3 4 bytes between btemp and the start of the buffer.
     
    But I do not understand what this code means and why it is there ...
    (ok, some sort of context-saving and -restoring before and after the ISR is executed)
     
     
     
    post edited by JBecker32 - 2018/05/01 08:02:10
    #11
    RISC
    Super Member
    • Total Posts : 5272
    • Reward points : 0
    • Status: offline
    Re: First byte of array overwritten 2018/05/01 08:05:32 (permalink)
    0
    Hi,
    the code you shows looks to me like interrupt save / restore code generated by the compiler.
    XC8 is not doing a very good job at saving restoring context for PIC18.
    I mean it generates quite a lot of code in the free version, just to be on the safe side...
    Make sure to minimize code within your interrupt.
    Are all global variables modified in the interrupt declared as volatile ?
    Regards
     
    #12
    du00000001
    Just Some Member
    • Total Posts : 2132
    • Reward points : 0
    • Joined: 2016/05/03 13:52:42
    • Location: Germany
    • Status: offline
    Re: First byte of array overwritten 2018/05/01 08:20:29 (permalink)
    0
    Looks like some 4-Byre scratchpad were saved. Not clear why the correct size is not "known' during memory allocation.
    Any more references in the .lst file(s) ?

    PEBKAC / EBKAC / POBCAK / PICNIC (eventually see en.wikipedia.org)
    #13
    JBecker32
    Starting Member
    • Total Posts : 39
    • Reward points : 0
    • Joined: 2012/12/17 02:30:04
    • Location: 0
    • Status: offline
    Re: First byte of array overwritten 2018/05/01 08:41:37 (permalink)
    0
    du00000001
    Looks like some 4-Byre scratchpad were saved. Not clear why the correct size is not "known' during memory allocation.
    Any more references in the .lst file(s) ?

    Looks like a bug to me. I do not see how I could influence this (mis-)behavior in my code ...
    post edited by JBecker32 - 2018/05/01 08:43:04
    #14
    NKurzman
    A Guy on the Net
    • Total Posts : 16446
    • Reward points : 0
    • Joined: 2008/01/16 19:33:48
    • Location: 0
    • Status: offline
    Re: First byte of array overwritten 2018/05/01 08:45:35 (permalink)
    +1 (1)
    volatile uint8_t Rx2Buffer[RX2BUFSIZE];
     all variables that are share with the interrupts should be declared volatile 
    #15
    JBecker32
    Starting Member
    • Total Posts : 39
    • Reward points : 0
    • Joined: 2012/12/17 02:30:04
    • Location: 0
    • Status: offline
    Re: First byte of array overwritten 2018/05/01 08:49:44 (permalink)
    0
    NKurzman
    volatile uint8_t Rx2Buffer[RX2BUFSIZE];
     all variables that are share with the interrupts should be declared volatile 

    Done that without any improvement. And Rx2Buffer is only used in one ISR, so no need to declare as volatile.
     
    7296 00005D btemp:
    7297 opt stack 0
    7298 00005D ds 1
    7299 0000 int$flags set btemp
    7300 0000 wtemp6 set btemp+1
     
    Seems that 'btemp' is supposed to only use one byte (ds 1). And then four bytes are read/written.  
     
    post edited by JBecker32 - 2018/05/01 08:51:14
    #16
    mlp
    boots too small
    • Total Posts : 595
    • Reward points : 0
    • Joined: 2012/09/10 15:12:07
    • Location: previously Microchip XC8 team
    • Status: offline
    Re: First byte of array overwritten 2018/05/01 09:48:31 (permalink)
    +1 (1)
    JBecker32
    I think I cannot post the whole code.

    Then you will be in a world of pain.
     
    You do not know what the problem is (because you posted here).
    Therefore you do not know what part of your code is responsible for triggering the compiler behaviour that you see.
     
    qɥb
    the bug is hidden somewhere in the code you have not shown us...

    Possibly yes. But the same code runs without problems when compiled with V1.33 to V1.38. And it runs if I introduce dummy variables (see first post).
     



    Then you need to chop out bits of your code until the problem disappears in v1.45, and then add back the last bit you chopped out and confirm that the problem returns. Keep doing this until you can't any more, and what you'll have is a Minimal, Complete, and Verifiable Example (stackoverflow), also known as a Minimal Working Example (wikipedia) or a Short, Self Contained, Correct Example (sscce.org). This example is what you will need to either show here for further help, or submit with your support case so the people who work on the compiler (not me any more) can reproduce the problem, fix it, and verify that it is fixed.

    Mark (this opinion available for hire)
    #17
    RISC
    Super Member
    • Total Posts : 5272
    • Reward points : 0
    • Status: offline
    Re: First byte of array overwritten 2018/05/01 10:00:44 (permalink)
    0
    Hi,
    JBecker32Seems that 'btemp' is supposed to only use one byte (ds 1). And then four bytes are read/written. 

     
    Be careful with that interpretation....
    The compiler is a tricky beast it just say that it copies btemp location, then  btemp+1, btemp+2 and btemp+3.
    It does not mean btemp is a 4 bytes type. It could be as an example that there are additional data in the following bytes and that the intermediate assembler use indexes to copy them...
     
    Can you try to look in debug mode to the GPR :
    Window > PIC Memory views > File Registers > Format : Symbol
     
    Have you tried to generate more detailed files :
    Project Properties window > XC8 global options > XC8 linker > option categories > reporting > display HEX usage map
     
    Regards
     
    #18
    Gort2015
    Klaatu Barada Nikto
    • Total Posts : 2668
    • Reward points : 0
    • Joined: 2015/04/30 10:49:57
    • Location: 0
    • Status: offline
    Re: First byte of array overwritten 2018/05/01 10:04:16 (permalink)
    0
    Chances are that you have changed your code since updating compilers.
    You introduced the bug in your own code that you have not shown.
     
    It's normally bad code or clutching at straws.

    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
    RISC
    Super Member
    • Total Posts : 5272
    • Reward points : 0
    • Status: offline
    Re: First byte of array overwritten 2018/05/01 10:07:30 (permalink)
    +1 (1)
    Hi,
     
    What you should show us is actually NOT the Window > Debugging > Disassembly but the 
    Window > Debugging > Output > Disassembly Listing File.
    If you have an error, just follow the instructions to enable disassembly listing file generation
     
    Then, attach your complete interrupt disassembly listing file
     
    Regards
     
    #20
    Page: 12 > Showing page 1 of 2
    Jump to:
    © 2018 APG vNext Commercial Version 4.5