完善资料让更多小伙伴认识你,还能领取20积分哦, 立即完善>
您好。我有一个下一个变量定义,编译之前对所有xc32版本没有错误(1.43)(1.42,1.40)。1.33).F浮等FWORSONDATABASEDAtiON属性((节)(KSEG1XDATAYMEM),地址(0xA000 01004),持久性);现在升级XC32编译程序1.43之后,我们有了一个新的编译器错误,现在不知道它是怎么回事,如何纠正它:错误:“Frimon HurdDigaDATA”的地址应该是16字节ALI。当使用相干属性时,Gothe fFron OnWorkDeasyAtAtditTyx((节)(KSEG1XDATAYMEM),地址(0xA000 01004),持久性);1,我们如何解决这个问题来保持固件从以前版本的可压缩性?2 -有人知道为什么微芯片升级会造成新的错误吗?在AdvestDeavy.P.D.D.D.D.中,我们需要保持这个变量和属性持久性,因为这个ADRSSS在应用程序的引导加载程序上加载了一些值。
以上来自于百度翻译 以下为原文 Hello. I have next variable definition that was compiling with no errors for ALL XC32 versions previous to 1.43( 1.42,1.40. 1.33 etc..) float fVersionHardWareDATA __attribute__((section("kseg1_data_mem"),address(0xA0001004),persistent) ); Now After upgrading XC32 Compiler to 1.43 we have a new compiler error and don´t now what it is wrong and how to correct it: error: Address of 'fVersionHardWareDATA' should be 16-byte aligned when the coherent attribute is used float fVersionHardWareDATA __attribute__((section("kseg1_data_mem"),address(0xA0001004),persistent) ); 1- How can we solve this problem to keep the compability of the Firmware from previous versions? 2- does anyone knows Why this microchip upgrade creates new errors? Best Regards And thank you in advanced David.- p.d. we need to keep this variable with the attribute persistent because this adresss is loaded with some values on the BOOTLOADER of the application. |
|
相关推荐
8个回答
|
|
检查一些配置开关(编译器设置),它控制浮点和/或连贯(持久)数据的对齐。另一种可能是声明一个从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. |
|
|
|
只有小组成员才能发言,加入小组>>
5055 浏览 9 评论
1940 浏览 8 评论
1877 浏览 10 评论
请问是否能把一个ADC值转换成两个字节用来设置PWM占空比?
3094 浏览 3 评论
请问电源和晶体值之间有什么关系吗?PIC在正常条件下运行4MHz需要多少电压?
2161 浏览 5 评论
603浏览 1评论
470浏览 1评论
有偿咨询,关于MPLAB X IPE烧录PIC32MX所遇到的问题
323浏览 1评论
PIC Kit3出现目标设备ID(00000000)与预期的设备ID(02c20000)不匹配。是什么原因
497浏览 0评论
405浏览 0评论
小黑屋| 手机版| Archiver| 电子发烧友 ( 湘ICP备2023018690号 )
GMT+8, 2024-9-13 00:23 , Processed in 1.328122 second(s), Total 92, Slave 75 queries .
Powered by 电子发烧友网
© 2015 bbs.elecfans.com
关注我们的微信
下载发烧友APP
电子发烧友观察
版权所有 © 湖南华秋数字科技有限公司
电子发烧友 (电路图) 湘公网安备 43011202000918 号 电信与信息服务业务经营许可证:合字B2-20210191