发 帖  
原厂入驻New
实战多通道高速精密测温仪的全系列设计教程,以实际项目为依托,提升工程师核心竞争力!→点击立即抢购←
[问答] DEE仿真16位地址陷阱问题
112 存储器
分享
大家好,我发现了一个问题,提供了一个1095,DEE仿真16位的代码。我已经广泛搜索论坛,没有看到这个特定的问题解决。我添加这个条目,以帮助任何未来的用户谁可能必须处理这个问题。我正在使用AM 1095,DEE仿真16位上的各种DSIC33 f…基于设备。我通常为2个ErOM仿真页面分配最高两页的程序内存(在我的例子中是0xA400…0xABFF)。该存储器用于存储配置参数和校准因子,通常不经常改变。正在开发的一个新设备需要对几个参数进行许多更改,这导致ErOM仿真固件提供了1095(DEE仿真16位。将页面从第0页切换到第1页,最后返回到第0页。在切换到第0页时,在执行PACKEY()函数时,处理器将有一个地址陷阱。我发现问题在“GETNEXTAVAIDCONTUTE()”函数中,这是PACKE调用的。此例程具有以下代码:退出DO的测试。而查找变量“i”小于页面中的指令数(* 2)。这个测试是在RealPyHyf()函数之后进行的,它已经尝试读取超出内存顶部的地址(PMOffice)。该函数在检查第一页时不会失败,因为错误地址仍在程序存储器空间内。因此,在程序内存空间中找到他们的ErOM仿真空间的用户将不会遇到这个问题。我选择使用for循环,因为它在试图读取内存之前将终止:这将阻止RealPyHyf()函数读取超出程序存储器顶部的TH。for for循环的E测试将强制在执行之前退出循环。我发现很难相信我是第一个体验这个问题的人。有没有办法纠正应用笔记?文斯

以上来自于百度翻译


      以下为原文

    Hi to all,
I have discovered a problem with the code provided with AN 1095, DEE Emulation 16-bit. I have searched the forums extensively and have not seen this particular issue addressed. I add this entry to help any future users who might have to deal with this.
I am using AM 1095, DEE Emulation 16-bit on various dsPIC33F... based devices. I typically allocate the highest two pages of program memory (in my case 0xa400..0xabff) for the 2 EEROM emulation pages. This memory is used to store configuration parameters and calibration factors, which usually do not change very often.
One recent device under development required many changes to several parameters, which caused the EEROM emulation firmware provided with AN 1095 (DEE Emulation 16-bit.c & .h) to switch pages from page 0 to page 1, and finally back to page 0. During the switch to page 0, while executing the PackEE() function, the processor would have an address trap.
I have found the problem to be in the 'GetNextAvailCount()' function, which is calLED by PackEE. This routine has the following code:
    do
    {
        i+=2;
        pmOffset += 2;
        dataEEval = (ReadPMHigh(pmOffset) & 0xFF);
    }
    while ((i<NUMBER_OF_INSTRUCTIONS_IN_PAGE * 2) && (dataEEval != 0xFF));

The test to exit the do..while looks for the variable 'i' to be less than the number of instructions in the page (*2). This test comes after the ReadPMHigh() function, which already has attempted to read the address (pmOffset) which is beyond the top of memory. This function does not fail while checking the first page, as the erroneous address is still within the program memory space. Because of this, users who locate their EEROM emulation space lower in program memory space will not experience this issue.
I chose to use a for loop as it will terminate before the attempt to read memory:
    for(i = 2; i < (NUMBER_OF_INSTRUCTIONS_IN_PAGE * 2); i += 2){
        pmOffset += 2;
        IF((ReadPMHigh(pmOffset) & 0xFF) == 0xff)
            break;
    }

This will prevent the ReadPMHigh() function from reading beyond the top of program memory as the test for the for loop will force an exit of the loop prior to its execution.
I find it hard to believe that I am the first to experience this issue. Is there a way to correct the app note?
Vince
0
2019-4-12 16:00:59   评论 分享淘帖 邀请回答
1个回答
谢谢,我用DEE 3次,在DSPIC33上“旧”和一个新的,看起来一切都好。

以上来自于百度翻译


      以下为原文

    Thanks for this, I used DEE some 3 times, on dsPIC33 "old" and a newer one too and it looked all ok.
2019-4-12 16:14:45 评论

举报

只有小组成员才能发言,加入小组>>

44个成员聚集在这个小组

加入小组

创建小组步骤

关闭

站长推荐 上一条 /10 下一条

快速回复 返回顶部 返回列表