访问程序空间中的常量编译错误？

貌似强制地址在15000是编译器允许的，但是不能检查“深入”…



      以下为原文

    Looks like forcing the address at 15000 is something that the compiler allows, but can't check "in depth" ...

是的，你必须使用y-uBuffTynTabLeRDL等来读取这些变量。所有的声明都是保留空间并初始化数组。你也可以使用PSV来更传统地阅读它们。



      以下为原文

    Yes, you have to use the __builtin_tablerdl, etc., to read back those variables.  All your declaration does is reserve the space and init the array.  You can also use psv to read them back more conventionally.

让我澄清一下：我检查了几种在Flash中声明缓冲区的方法：1。const无符号int MyFlash内存[32 ]＝{1，2，3，4，5，6，7，8}；2。const无符号int yAtAtditTyx（（地址（0x15000）））MyFlash存储器[32 ]＝{1，2，3，4，5，6，7，8}；3。const无符号int yAtAtditTyx（（空间（PSV），地址（0x15000）））MyFlash存储器[32 ]＝{1，2，3，4，5，6，7，8}；4。const无符号int yAtAtditTyx（（空间（PROG），地址（0x15000）））MyFlash存储器[32 ]＝{1，2，3，4，5，6，7，8}；5。（32）[1，2，3，4，5，6，7，8}；6。（32）{ 1，2，3，4，5，6，7，8}；一些定义引起麻烦。（使用本测试的模拟器）1。编译器将常数放置在名为“.const”（在我的例子位于0x000 0300）的LoWordDebug [K]＝MyFlash内存[k}的区段中，代码是OK的。编译器将DSRPAG设置在不可见代码中的任何地方到0x0200，并用MOV[W0]读取MyFlash空间的第一个字。W0＝0x8300，即偏移0x0300和比特15设置为指示PSV/EDS访问。2。一个地址是放置常量的地方。在这种情况下，编译器生成警告：MyFlash内存不被放置到编译器管理的PSV部分（由于地址（））；假设空间（PSV）为“MyFlash内存”。常量放置在地址为0x15000的Flash中，代码类似于1。但是DSRPAG被设置为0x001而不是0x0202。（0x00万…0x07FFF-&；DSPPAGG＝0x200；0x00 8000…0x00 FFFF & &；DSPPAG＝0x0201；0x010000…0x017FFF & &；dSPPAG＝0x0202），因此结果是错误的，有时运行此代码模拟器崩溃（没有单步执行，没有重置，没有完成调试会话可能）。重新启动MPLAB X（V3.45）需要3.3显式使用空间（PSV）：没有警告，没有错误，常量放置在闪存在0x15000。同样的问题和2一样。DSRPAG是0x00 01，模拟器崩溃从RAM的EDS页1读取（而不是从程序存储器读取）4。没有警告，没有错误。但是代码是完全错误的。5。没有警告，没有错误。代码好。DSRPAG被设置为UnWord指令＝MyFlash存储器；6。没有警告，没有错误。代码好。代码与5略有不同，问题是3。4。在那里你既没有警告也没有错误，但是这些值是从ELSE读取的，而不是从程序内存中的常量读取的。



      以下为原文

    Let my clarify:
I checked several ways to declare the buffer in Flash:
 
1. const unsigned int myFlashMemory[32]={1,2,3,4,5,6,7,8};
2. const unsigned int __attribute__((address(0x15000)))  myFlashMemory[32]={1,2,3,4,5,6,7,8};
3. const unsigned int __attribute__((space(psv),address(0x15000)))  myFlashMemory[32]={1,2,3,4,5,6,7,8};
4. const unsigned int __attribute__((space(prog),address(0x15000)))myFlashMemory[32]={1,2,3,4,5,6,7,8};
5. __psv__ const unsigned int __attribute__((space(prog),address(0x15000)))  myFlashMemory[32]={1,2,3,4,5,6,7,8};
6. __eds__ const unsigned int __attribute__((space(prog),address(0x15000)))  myFlashMemory[32]={1,2,3,4,5,6,7,8};


Some of the definitions are causing trouble.
(used the Simulator for this Test)
1. The compiler places the constants at a section named ".const" (in my Example located at 0x000300)
LowWordInstructions[k]=myFlashMemory[k}; code is OK.
The compiler has set DSRPAG anywhere in the non-visible code to 0x0200 and reads the first word of myFlashSpace with MOV [W0],.. with W0=0x8300 i.e. offset 0x0300 and Bit 15 set to indicate PSV/EDS access.
 
2. An address is where the constants are placed.
In this case the compiler generates a warning:
warning: myFlashMemory Not placing into compiler managed PSV section due to address(); assuming space(psv) for 'myFlashMemory'.
The Constants are placed in Flash at address 0x15000 and the code is similar to 1. But DSRPAG is set to 0x0001 instead of 0x0202. (0x000000 ... 0x007FFF->DSPRPAG=0x200; 0x008000...0x00FFFF->DSPRPAG=0x0201; 0x010000...0x017FFF->DSPRPAG=0x0202) So the results are wrong and sometimes running this code the Simulator crashes (no single-stepping, no reset, no Finish Debug Session possible. Restart of MPLAB X (v3.45) required)
 
3.Explicit using space(psv): No warnings, no errors, constants placed in Flash at 0x15000. Same Problem as with 2. DSRPAG is 0x0001 and simulator crashes reading from EDS-Page 1 of RAM (instead of reading from Program memory)
 
4. No warnings, no errors. But code is totally wrong.
 
5. No warnings, no errors.Code OK. DSRPAG is set explictite  for LowWordInstructions=myFlashMemory;
 
6. No warnings, no errors.Code OK. Code slightly different from 5.
 
The problems are 3. and 4. where you get neither warning nor errors but the values are read from elswhere but not from the constants in program memory.
 
 
 

你到底想做什么？这些方法中有很多是针对特定用途的。你有特殊需要吗？Const将工作，但限于32 K。



      以下为原文

    What are you trying to actually do?
Many of those methods are for specific uses.
You you have a special need?
Const will work, but is limited to 32k.

事实上，我不想做任何事情。有一些线索：我不能擦除一个Flash页面，或者我不能编程Flash。通常问题是，你无法看到MPLAB X的“真实”内存值。闪存没有更新。你可以尝试“从设备读取内存”来读取所有闪存。长期运行和MPLAX X不总是可能的。或者你可以离开IDE，进入IPE并读取设备内存。不是一个非常集成的方式。通常用户希望在Flash中存储永久数据。他们选择要手动存储数据的位置，例如：存储在0x015000和以下位置。然后，他们需要擦除一页Flash（它不是AlRADY 0xFFFFFF）并编程值。他们想检查擦除和程序是否成功。他们需要一个简单的方法来做这件事。我的假设是在程序内存中显式地分配一个缓冲区作为无符号int闪存缓冲器[nnnn]。然后读取闪存的较低的16位应该通过简单的诸如MyRAMBuff[k]＝Flash缓冲器[K]来完成，而不使用AuxBuffTiNiTBRRDL（），这可能是启动用户的另一个负担。程序存储器中的NSTANT——缓冲器位于Flash中。地址（0x15000）可能是含糊不清的，如果设备有很多RAM。我的第一个代码发生了什么：我擦掉了一个最初是0x00万的闪存页面，我是舒尔，我可以擦除它，然后用MyRAMBuff[k]＝Flash缓冲器[K]读取。但是，在RAM中没有“0xFFFF”，我还有一些其他的值。LY 0x000也是非零值（我是用真正的硬件和ICD3做的）。正是这些非零值导致我假设编译器生成的代码读取闪存缓冲区的错误，而不是用擦除页代码。我可以为我解决这个问题，因为我更喜欢汇编编程，并且可以自己管理TBLRD和EDS访问。但是，在C中应该有一个简单的和被推荐的方法。我曾被告知，由于性能，Flash在调试器会话中没有被更新。我认为这不是原因。如果开发人员在Flash中分配内存（未声明为const），他很可能会将一些数据编程到此内存中。如果他把这一点——也许只有几句话——对监视窗口的记忆——他的意图是明确的。如果程序员/调试器必须刷新每个断点/单步骤的整个程序存储器，这将是一个性能问题。但我唯一期待的是阅读Flash我在手表窗口中添加的内容。这将不会比从设备读取RAM长度相等的缓冲区花费更长的时间，这将节省开发人员在Flash编程方面的大量时间。



      以下为原文

    Actually I'm trying nothing to do.
There are some threads like: I can't erase a page of Flash or I can't program Flash.
Often the problem is only that you can't see the "real" memory values with MPLAB X. Flash is not updated. You can try "read memory from device" to read back all Flash. Long lasting operation and with MPLAB X not always possible. Or you can leave IDE, enter IPE and read device memory there. Not a very Intergrated way.
Often users want to store permanent data in Flash. They select the Location where they want to store the data manually, for example: store at 0x015000 and following locations. Then they need to erase a page of Flash (it it is not alredy 0xFFFFFF) and program the values. And they want to check whether the erase and program was successful.
They need a simple way to do this.
My assumtion was to explictely allocate a buffer in program-memory as unsigned int FlashBuffer[nnnn]. Then reading the lower 16 bits of the Flash should be done by simply such things like:
MyRamBuffer[k]=FlashBuffer[k] and without using __builtin_tblrdl() which might be another burden for a starting user.
The qualifier const i only used in this example to be shure - together with the option: store constants in program-memory- that the buffer is located in Flash. address(0x15000) can be ambiguos if the device has a lot of RAM.
 
What happend with my first code: I erased a page of flash which was initially 0x000000, I'm shure I can erase it, then read back with myRamBuffer[k]=FlashBuffer[k].
But instead of having "0xFFFF" in the RAM I had some other values, mostly 0x0000 but also non-zero values (I did it whith real hardware and ICD3). And just these non-zero values lead me to the assumption that something is wrong with the compiler generated code for reading FlashBuffer - and not with the erase-page code.
 
I can solve this for me as I prefer assembly programming and can manage tblrd and eds-access by my own. But there should be a simple and recommened way to do it in "C".
 
I was once told the Flash is not updated in the debugger session due to performance. I think this is not the reason. If a developer allocates memory in Flash (not declared as const) he most likely does to program some data to this memory. And if he adds this -maybe only few words- of memory to the watch window his intention is clear.
 
It would be a performance issue if the programmer/debugger had to refresh the whole program-memory every breakpoint/single-step. But the only thing I expect is to read that protion of Flash I added to the Watch-window. And this will not last much longer than reading a buffer of equal length of RAM data from the device.
 
This would save a lot of time for developers struggeling with Flash programming.
 
 

支持Weydert：（我在EEPROM中有变量，在某些情况下可能会被我的程序改变，而其他可能是在I2C接口后面的芯片外）如果我用编译器支持的限定符来定义或声明变量，那么我通常会期望一个警告（O）。如果访问不能按预期工作，则存在链接错误，因为访问方法丢失。并不是说我不希望编写特殊的硬件解锁序列来编写Flash或EEPROM。这是一个泛泛之谈，就是在构建过程中尽快要求事情失败——在一个失败的构建中读取比在上面调试我的方法快得多。



      以下为原文

    In support of Weydert: (I have variables in EEPROM which may be altered under certain circumstances by my program, and others that may be off-chip behind an I2C interface)
 
If I define or declare variables somewhere, using the qualifiers supported by the compiler, then I generally expect a warning (or a link error because an access method is missing) if an access isn't going to work as expected.  Not that I don't expect special hardware unlock sequences for writing to program flash or even EEPROM.
 
This is a generalization of asking for things to fail as soon as possible in the build process -- it is much quicker to read up on a failed build than to debug my way to the above.
 

你正在寻找一个通用问题的解决方案。在工具箱中抛出每一个WHOUT都是无济于事的。一般最小的情况是：const unStimeint ItAtAtthiTyx（（AlgIn（Flash，PaGig.Sige））数据[Flash，PaGig.Sige]；（是的，DO可以得到与其他语句相同的结果）。将链接器放置在PSV中的地址和不冲突的地址。它占用一个完整的Flash页面，这样它就不会减轻代码或其他的死点。你需要从RAM/PSV地址中得到实际的Flash地址。然后你可以擦除它并给它写。MPLABX不自动读回闪存。或者EEPROM。您需要读取它，或者将其复制到代码中的RAM中，以调试它。



      以下为原文

    You are looking for a general solution to a general problem.
Throwing every wench in the tool box at will not help.
The General smallest case:
const unsigned int __attribute__((align(FLASH_PAGE_SIZE))data[FLASH_PAGE_SIZE];
( and yes do could get the same results with other statements).
Now you have a block that the linker will place in the PSV and an address that will not conflict.
And it takes up a full flash pages so it will not ease code or other consts.
You need to get the actual Flash address from the RAM/PSV address.
Then you can erase it
And write to it
The MplabX does not auto read back Flash or EEPROM.
You need to either read it back, or copy it to RAM in your code to debug it.
 
 

再说一遍：编译器对这个小程序生成的代码是错误的。



      以下为原文

   
#include "xc.h"
#define FLASH_PAGE_SIZE 1024
const unsigned int __attribute__ ((space(prog), aligned(2*FLASH_PAGE_SIZE)))data[FLASH_PAGE_SIZE]={1,2,3,4};
unsigned int LowWordInstructions[32]; //to read back the 16 lower bits of instructions
//******************************************************************************
int main(void) {
    unsigned int k;
    for (k=0;k<32;k++)
    {
        LowWordInstructions[k]=data[k];
    }
    while(1);
    return 0;
}

To tell again: The code generated by the compiler for this small piece of program is wrong.
! LowWordInstructions[k]=data[k];
0x30C: MOV [W14], W0 ;W0: index k
0x30E: ADD W0, W0, W1 ;2*k
0x310: MOV #0x800, W0 ;starting address of data
0x312: ADD W1, W0, W0 ;address of data[k]
0x314: MOV [W0], W1 ;read from RAM not from Flash
0x316: MOV [W14], W0
0x318: ADD W0, W0, W2
0x31A: MOV #0x1000, W0
0x31C: ADD W2, W0, W0
0x31E: MOV W1, [W0]

 
   Attached Image(s)

Weydert有自己的解决办法。他正在报告编译器错误，可能MPLAX X比它更难使用。



      以下为原文

   
Weydert has his solution.  He is reporting a compiler bug, and possibly that MPLAB X is harder to use than it should be.
 

Weydert有自己的解决办法。他正在报告一个编译器错误，可能MPLAX X比它应该使用的要难。OKI没有得到它。我得到了：我试过6种不同的方式来做这件事，我不能得到任何工作。如果他们怀疑一个bug。他们需要将线程标记为这样，并演示bug。编译器编写者检查这个论坛以解决编译器问题。与编码课程无关。是的，MPLABX可能比它更难使用，但是您需要单击“读取”以查看Flash和EEPROM的更改。阅读每一步后的闪回会使调试速度变慢。



      以下为原文

   
Weydert has his solution.  He is reporting a compiler bug, and possibly that MPLAB X is harder to use than it should be.
 


Ok
I did not get that.
I got: I tried 6 different ways to do this and I can't get any to work.
IF they suspect a bug. They need to label the thread as such and demonstrait the bug.
The Compiler writers do check this forum for compiler problems.  Not so much for coding lessons.
Yes MplabX may be harder to use than it could be, But you need to click "read to see Flash and EEPROM changes.  Reading the Flash back after each single step would make Debugging a new level of slow.
 
 

事实上，我希望调试器在每一步中断时都能读取所有的Flash。



      以下为原文

    Indeed, I'd expect the debugger to be beyond slow if it read *all* of flash at every single-step interrupt. 
 
Now, how would Weydert change the thread title to something informative?

我认为他可以改变它，如果他编辑后1



      以下为原文

    I think he can change it if he edits post #1