数组的第一个字节被覆盖

如果您使用编译后的堆栈模型，BTEMP可以创建为AAA Auto[ft]（“堆栈”）变量的替代品。MAP文件可能（或可能不）告诉您该变量是从哪里引用的。否则，您可能能够将数据断点设置为此变量（取决于可用的HW特性）。



      以下为原文

    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).

这些是如何定义的？中断发生了什么？



      以下为原文

    How are these defined? What is happening in the interrupt?

在.map文件中，我在符号表中找到下面的内容：BTEMP TEMPO90005D…INT$FLAG TEMPOP 09005D…[字体=“%值”）“INT$FLAG”是什么意思？但是，即使它驻留在0x5D，为什么0x60用0重写？



      以下为原文

    In the .map file I find the following in the symbol table:

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

这个bug隐藏在代码中的某个地方，你没有告诉我们…



      以下为原文

    the bug is hidden somewhere in the code you have not shown us...
 

某些ISR代码中的“标志”变量吗？M8GHT是一个int（5E和5F），携带一些值：中断，初始化这些（例如用零）和重置，只是为了看到这些被重写。进一步的细化可能会使你更接近“影响区域”。（3字节的影响看起来像是一个24位浮点变量的“滥用”）。



      以下为原文

    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.)
 

定义了Rx2BuFigS32 UIT88T RX2缓冲区[RX2BufSig]；我认为我不能发布整个代码。但是在ISR中有一个状态机，其中一个在另一个接收字节之后被存储在RX2缓冲器中。在第一个字节存储在Rx2缓冲区[0 ]之后，我可以在那里看到它。但是这个位置在从ISR返回到主代码之后被清除。所有其他字节都存储在没有问题的情况下。如果将Tx2缓冲区设置为更大的大小，也会发生同样的情况。然后它位于0x60（而不是Rx2缓冲器）。同样的情况也发生了。我将一个字节存储在Tx2缓冲区中，然后TX中断触发，当进入TX ISR时，第一个缓冲区是空的，可能是。但是，当用V1.33编译到V1.38时，相同的代码运行没有问题。如果我引入哑变量（见第一篇文章），它就会运行。



      以下为原文

   
#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. 
 
 

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).
 
 

如果清除内存位置0x5e和0x5f，则它们再次被更改为其他值。嗯，为什么编译器/链接器把它放在这里，以便它覆盖数组？而且，不，它被放置在不同的RAM区域。我不使用浮动（从不）。



      以下为原文

   
 
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). 
 

似乎BTEMP用于超过其声明大小的变量。指针“野生”怎么办？也许有助于设置警告水平尽可能低的ANF叉通过所有警告抛出…



      以下为原文

    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...

我现在看到了一些东西，但是我还不明白它……如果我把视图转换成“拆解”和单步通过代码，在从HygiSISR ISR返回之后，有一个语句：0xD0A:MOVF0x40，Rx2Buffrand，这清除了Rx2缓冲器的第一个位置。但是我看不出这个位置在哪里。代码来自……？？？？如果（PrI3BIT.CCP2IF）/Time1比较中断0xCF8:BTFSS PIR3，2，Access！{！啊！PIR3BIT.CCP2IF＝0；0xCFC:BCF PIR3，2，Access！PY3BITS.CCP2IE＝1；0xCFE:BSF PIE3，2，Access！In ununn= 0x01；//为看门狗0xD00：MOVLW 0x1！doEvySub MS-（；）//1ms Tasks0xD06：调用0x13b6，0！谢谢！}！}0xd0a:MOVFF 0x40，RX2缓存！虚空每空（空）！{！静态UTI8T T 1MSCNT；BLink K5S ++；0x13B6:CIF BLink K5S，F，Access！此代码位于Hixi-ISR ISR的关闭支架之后。



      以下为原文

    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. 
 
 
 

在.LST文件中，我看到如下：4141 000 0D0A C041 F060 MOVFF？？高HISR + 17，BTEMP + 3 4142 000 0DE C040 F05F MOVFF？？高HISR + 16，BTEMP + 2 4143 000 012 C03F F05E MOVFF？？高HISR + 15，BTEMP + 1 4144 000 D16 C03E F05D MOVFF？？高HISR + 14，BTEP 4145 000 0D1A C03D FFF5 MOVFF？？高HISR + 13，TabLAT 4146 000 01E C03C FFF8 MOVFF？？高HISR + 12，TBLPTRU 4147 000 D22 C03B FFF7 MOVFF？？高HISR + 11，TBLPTRH 4148 000 026 C03A FFF6 MOVFF？？高HISR + 10，TBLPTRL 4149 000 0D2A C039 FFF4 MOVFF？？高HISR + 9，PRODH 4150 000 02E C038 FFF3 MOVFF？？高HISR + 8，PRODL 4151 000 032 C037 FFDA MOVFF？？高HISR + 7，FSR2H 4152 000 036 360FFD9 MOVFF？？高HISR + 6，FSR2L 4153 000 0D3A C035 FFE2 MOVFF？？高HISR + 5，FSR1H 4154 000 0D3E C034 FFE1 MOVFF？？高HISR + 4，FSR1L 4155 000 D42 C033 FFEA MOVFF？？高HISR + 3，FSR0H 4156 000 D46 C032 FFE9 MOVFF？？高HISR + 2，FSR0L 4157 000 0D4A C031 FFFB MOVFF？？高HISR + 1，PCLATU 4158 000 0D4E C030 FFFA MOVFF？？高HISISR，PCLASE 4159 000 0D52 925D BCF BTEMP，1，C；清除编译器中断标志（级别2）4160 000 054 54 0011 RIFFE F 4161 000 056 56ON Enthi of HyHysISR：似乎BTEMP是长的，这将解释为什么在BTEP和缓冲器的开始之间有小于34个字节的缓冲区被覆盖。但是我不理解这个代码意味着什么以及它为什么在那里……（好的，在执行ISR之前和之后的某种上下文保存和恢复）



      以下为原文

    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)
 
 
 

您好，您所显示的代码看起来像Cimulel.xC8生成的中断保存/恢复代码，在保存PIC18恢复上下文方面做得不是很好。我的意思是它在免费版本中生成了大量代码，只是为了安全起见…请确保在您的INT中最小化代码。在中断中修改的全局变量是否被声明为易失性？当做



      以下为原文

    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
 

看起来像是保存了4个ByRE便笺簿。不清楚为什么正确的大小在内存分配中不是“已知的”。在LST文件中有更多的引用吗？



      以下为原文

    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 ...

易失的UIT88T RX2缓冲区[RX2BuFSCASI]；所有与中断共享的变量都应声明为易失性。



      以下为原文

    volatile uint8_t Rx2Buffer[RX2BUFSIZE];
 all variables that are share with the interrupts should be declared volatile 

这样做没有任何改进。RX2缓冲区只在一个ISR中使用，所以不需要声明为Value.729 6000×5D BTEMP：7297个OPT堆栈07298个O9005D DS 17299个0000 INT$标志集BTEMP7300 0000 WTEMP6设置BTEMP+1似乎“BTEP”只需要使用一个字节（DS 1）。然后读取/写入四个字节。



      以下为原文

   
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.  
 

然后你将处于一个痛苦的世界。你不知道问题是什么（因为你在这里张贴）。因此，你不知道你的代码的哪个部分负责触发你所看到的编译器行为。可能是。但是，当用V1.33编译到V1.38时，相同的代码运行没有问题。如果我引入了哑变量（参见第一篇文章），它就运行了。然后，你需要把代码的位切掉，直到V1.45中的问题消失，然后再加上最后一个被切掉的比特，并确认问题返回。一直这样做，直到你不能再，你会有一个最小的，完整的，可验证的例子（StAdvOpForm），也称为一个最小的工作示例（维基百科）或一个简短的，自给自足的，正确的例子（SSCCE.org）。这个示例是您需要在这里显示的进一步帮助，或者提交您的支持案例，以便在编译器上工作的人（不再是我）可以重现问题，修复它，并验证它是固定的。



      以下为原文

   
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.
 

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.

嗨，小心这个解释…编译器是一个棘手的畜牲，只是说它复制了BTEMP位置，然后BTEMP +1，BTEMP +2和BTEMP+3。这并不意味着BTEMP是一个4字节类型。它可以是一个例子，在下面的字节中有额外的数据，中间汇编程序使用索引来复制它们……你可以尝试在调试模式下查看GPR：窗口& GT；PIC内存视图& GT文件寄存器&格式：符号：你试图生成更详细的数据吗？文件：项目属性窗口& gt；xC8全局选项& gt；xc8链接器& gt；选项类别& gt；报告和显示十六进制用法MaPosits



      以下为原文

    Hi,
 
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
 

可能是自从更新编译器以来，你已经改变了你的代码。你在你自己的代码中引入了你没有显示的bug。它通常是坏代码或者抓在草根上。



      以下为原文

    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.

嗨，你应该告诉我们实际上不是窗口& gt；调试&拆卸；但是窗口& gt；调试& gt；输出& gt；拆解列表文件。如果你有一个错误，只需按照指令来启用反汇编列表文件生成，然后附加完整的中断反汇编。列出文件目录



      以下为原文

    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