在XC32 1.43上编译器错误

检查一些配置开关（编译器设置），它控制浮点和/或连贯（持久）数据的对齐。另一种可能是声明一个从0xA000 01000开始的持久结构。作为偏移4的成员。



      以下为原文

    Check for some configuration switch (compiler settings) that controls the alignment of float and/or coherent (persistent) data.
An alternative might be to declare a persistent struct starting at 0xA0001000 - having your fVersionHw... as a member with offset 4.

可能是由于下面的发行说明：这可能是16字节对齐要求来自的地方。现在对于WTF显式非缓存（KSEG1）数据必须是高速缓存对齐的是任何人的猜测。



      以下为原文

    Probably due to the following from the release notes:-

This is probably where the 16byte alignment requirement comes from.
 
Now as to WTF explicitly non-cached (kseg1) data has to be cache aligned is anybodys guess.

这是因为缓存在16字节行上运行。这意味着，如果在同一个16字节高速缓存行地址中有一个缓存变量作为非缓存变量，则当缓存行写入RAM时，非缓存变量会被损坏。工具链现在试图抓住这个潜在的问题。



      以下为原文

   
This is because the cache operates on 16-byte lines. This means that if you have a cached variable in the same 16-byte cache-line address as your non-cached variable, the non-cached variable would get corrupted when the cache line is written to RAM. The toolchain now tries to catch this potential problem.

@ JasonKWoah！你是对的，只是用下面的代码进行测试。变量未被缓存在缓存行刷新中。这将是很难调试的。然而，WRT是OP的问题，如果将地址属性用于在KSEG1中放置变量，而不是将缓存行排除在KSGE0变量的链接器上，那不是更好吗？韩建失败了？这将破坏现有代码。当前（V1.43）方法对于具有相干属性的变量是很好的。编辑：实际上，我用V1.42.对V1.43进行了测试，我稍稍修改了变量定义：-从映射文件中可以看出，使用持久属性，“未被清除”被放置在KSEG1中，并且它编译的机智。没有警告，“未被清除的”像以前一样被重创。因此，“对齐”误差只是部分解决方案，所以毫无意义。我认为它应该失败，如果和仅当任何高速缓存线都包括KSGE0和KSG1地址，链接器避免混合它们根据发行说明和我以前的评论。



      以下为原文

    @JasonK
Woah! You are right.
Just tested with the following code. The variable uncached gets stomped on the cache line flush.
volatile unsigned __attribute__((address(0xa0001000))) uncached=0;
volatile unsigned __attribute__((address(0x80001004))) cached=0;
 
void FlushDCache(void *addr,int len)
{
    for(;len;len-=16,addr+=16)
    __builtin_mips_cache(0b11001,(void *)addr);
}

int main(void)
{
    cached=0xDEADBEEF;
    uncached=0xFA57F00D;
    FlushDCache(&cached,16);
    while(1)
    {
    }
 
}
That would be *hard* to debug.
However, wrt the OP's problem, wouldn't it be better to just exclude the cache line from being available to the linker for kseg0 variables if the address attribute is used to place a variable in kseg1, rather than fail to build? This would break less existing code. The current (v1.43) method is fine for variables with just the coherent attribute.
 
Edit:- Actually I tested the above with V1.42.
With V1.43 I slightly modified the variable definitions to:-
volatile unsigned __attribute__((persistent,address(0x80001000))) uncached; //Persistent implies coherent, addr=0xa0001000
volatile unsigned __attribute__((address(0x80001004))) cached;
from the map file it shows that with the persistent attribute, 'uncached' is placed in kseg1
.uncached.uncached
                0xa0001000        0x4
 .uncached.uncached
                0xa0001000        0x4 build/default/debug/_ext/1472/main.o
                0xa0001000                uncached

and it compiled with no warnings, with 'uncached' being clobbered as before. So the 'alignment' error is only a partial solution, so pointless. I think it should fail if and only if any cache line includes both kseg0 and kseg1 addresses, with the linker avoiding mixing them as per the release note and my previous comment.
 

实际上，您应该只使用KSG0地址作为数据变量，但是我们从编译器中删除了地址范围错误检查。有些客户有一些理由将变量放在链接器脚本定义的内存区域之外。



      以下为原文

    Really, you're supposed to use only kseg0 addresses for data variables, but we removed the address-range error checking from the compiler. Some customers had some reasons to place variables outside of the linker-script defined memory regions.
 

大家好：首先，非常感谢你们所有人的回答，但我仍然不知道如何处理这个错误。用编译器版本XC1.43，以上这行工作OK。BUTE，因为这个变量的值（fFrEnWorkStaseDebug）在Bootloader源代码中被填充，稍后Meal.C程序读取这个ADRESSS中的值，所以变量必须在这个特定地址的Meal.C中定义以获得该值。内存不被保存，值被读取为“0”，因为它从来没有被写入过。这就是为什么我需要使用这个定义ValueNoSurvivyAtEdTyx（（持久性，地址（0xA000 01004））fVeston HealthDebug；并且这个定义仍然在1.43和1.44编译器//Fif/Iffy1中给出错误。V02. C:218:2:错误：当使用相干属性时，“FrEnWorkHurWorkDATA”的地址应该是16字节对齐的，FraveBooSyAtAtditTyx（（持久性，地址（0xA000 01004）））Frimon HraveDATA；因此，我如何继续使用这个变量来处理这个变量？非常感谢你。大卫。



      以下为原文

    hello everyone:
 
First of all , thank you very much to all  you for your answers,
 
But still I don´t know how to deal with this error.
 
with Compiler Version XC1.43 and above  this line works ok.
 
 volatile unsigned __attribute__((address(0xA0001004))) fVersionHardWareDATA;
 
But I need to add the persistent attribute, Because  the value of  this variable (fVersionHardWareDATA) 
is filled on the Bootloader source code, and later the main.c program reads the value at this adresss, 
so the variable must be defined in the main.c  at this specific address to get that value.
If the variable is not defined as persistent,
the memory is not kept and the value is read as "0", as it hadn´t been never written.
 
that is why I need to use this definition
 
 volatile unsigned __attribute__(((persistent,address(0xA0001004))) fVersionHardWareDATA;
 
and this definition is still giving the error in 1.43 and 1.44 compiler.
 
./Info/Info_1v02.c:218:2: error: Address of 'fVersionHardWareDATA' should be 16-byte aligned when the coherent attribute is used
volatile float __attribute__((persistent,address(0xA0001004))) fVersionHardWareDATA ;
 
 So how could I keep using this address for this variable?
 
Thank you very much in advanced.
David.

我想Microchip可以发布一个新版本的编译器，使这个16字节对齐成为一个警告，而不是一个错误。最终，你需要改变Bootloader和应用程序中的持久性/一致性地址，以避免潜在的数据损坏。我猜想，你可能已经有产品在外地，所以改变引导装载机可能不是一个选项。如果是这种情况，你必须在V1.43版本之前使用任何XC32。



      以下为原文

    I suppose Microchip could release a new version of compiler that makes this 16-byte alignment a warning instead of an error. 
 
Ultimately you'll need to change the persistent/coherent address in both the bootloader and the application to avoid potential data corruption.  I am guessing that you probably have products already out in the field, so changing bootloader may not be an option. If this is the case, you'll have to use any XC32 prior to the v1.43 release.

或者使用链接器脚本和区段属性来放置变量。



      以下为原文

    Or use the linker script and a section attribute to place the variable.