N76E003双DPTR设计缺陷及其解决方案

只看该作者 · 2018-8-17 00:24

本帖最后由 ztb 于 2018-8-17 10:03 编辑

双数据指针DPTR,通过AUXR1+1切换指针用于批量数据移动使得程序变得简洁，是增强型51单片机的标配。
近来在使用双DPTR从Code区移动数据到Xdata时发现问题：
Code区地址=3700h，Xdata区地址=280h，移动数量128字节。
一般情况下，默认是DPTR0指向Code区，DPTR1指向XData区。程序很简单却怎么也不能通过，而用模拟
仿真却可以验证程序正确。随后逐步排查摸索规律终于发现是单片机的一个缺陷。
表现是：
dptr0<300h dptr1<300h 一切正常
dptr0<300h dptr1>2ffh 一切正常
dptr0>2ffh dptr1=任意切换到dptr1时，从Xdata读出的全部=00,也不能写入!

原因找到了，解决的方法就有了。很简单：
在程序最前面插入指令切换到DPTR1为默认指针
orl AUXR1,#1
就一切如常了。因为N76E003的XData最大为2FFh，从此天下太平！
还有注意，如果程序中切换了数据指针，必须恢复到DPTR1为默认。

各位，不知道你们遇到过类似表现莫名其妙的问题吗？

只看该作者 · 2018-8-17 06:48

大神，你用的汇编啊，我们用c，应该编译器自己处理了。

只看该作者 · 2018-8-17 10:02

wahahaheihei 发表于 2018-8-17 06:48
大神，你用的汇编啊，我们用c，应该编译器自己处理了。

如果你的这个说法成了,C编译器应该首先知道有这个BUG才能注意躲避.但是,程序结构千变万化特别是在具有多个不同优先级中断中也改变DPTR指针时很难完全躲避这个问题.
这个问题的表现是:只要符合条件,就突然"关闭"了XData,读出的全是00.条件解除后才"打开"恢复原值.
倒是可以利用这个BUG给代码加密了.

1万 · 2018-8-17 11:03

大神这种问题我就发现不了

只看该作者 · 2018-8-17 11:28

磨砂发表于 2018-8-17 11:03
大神这种问题我就发现不了

曾经想先绕过这个问题,但是担心是自己哪个部分程序导致的.所以才下功夫排查.

我的经验:如果在程序里面发现不能解释的现象,就一定是有不知道的问题存在.
今天绕过明天也许就会爆发.那时的代价就不是耽误几天时间可以弥补的了!

只看该作者 · 2018-8-17 12:16

希望新唐下次出这个相关的例子，我只会C啊

只看该作者 · 2018-8-17 12:30

是新唐BSP里哪个xRAM_768byte.c例子里面说的汇编内容吗

只看该作者 · 2018-8-17 14:13

xinpian101 发表于 2018-8-17 12:30
是新唐BSP里哪个xRAM_768byte.c例子里面说的汇编内容吗

不是xRAM例子里面的代码。我在例子里找到一个，是汇编写的和双指针毫无关系。
里面的第一，第二行还是错误的，“MOV DPH,0” 0前面缺少了“#”。
看后面的 read check的写法就验证了这个错误。所以我相信这个例程是没有经过
运行验证的！类似情况还出现在其它例程中，可见这些例程是不能轻易相信的。

我的实验代码见另一个帖子:
N76E003模拟仿真不支持双 DPTR?