Dspic33fj256gp710空闲命令期间的地址错误导致PORTB读取0

您好，我正在使用一个DSPIC33 FJ256GP710芯片工作在一个项目，其中包括一个键盘。键区列连接到PORTB。目前，我每10毫秒扫描一次键盘，但是经过一段随机时间（1到22分钟），设备只会读取0的PoTB，即使这些是由上拉电阻保持高的。这指示设备每个按钮同时被按下，这会导致各种各样的问题。我使用我的调试器发现地址错误中断是在设备停止工作之前被调用的。这是在设备处于瞌睡模式下完成的（如果在一个特殊的函数寄存器中写入，这是在地址错误中断期间，为了清除标志In CONCONDITY，AdReRR＝0），则会造成问题，导致地址错误中断。激活是在下面的函数中调用的IDLE（）函数：空隙MyDaly（空隙）{//CKDIVITOS.doZE＝0；/*使用所有外围设备的16MHz，但将周期执行打瞌睡到16MIPS*///CKDIVBITS。doZE＝1；/*使用所有外围设备的16MHz，但do-the循环执行DOW。DoZE＝2；/*使用所有外围设备的16MHz，但将周期执行打瞌睡降低到4MIPS*///CKDVIDES。doZE＝3；/*使用所有外围设备的16MHz，但将循环执行打瞌睡到2MIPS*/CKDIVITOS.ROI＝1；/*在中断*/NOP（）上自动返回全速。（1）；/*瞌睡使能在指令*/NOP-（）之前和之后必须有一个NOP；CKDIVBITS。doZE＝4；/*使用所有外围设备的16MHz，但将循环执行打瞌睡到1MIPS*/IDLE（）；}我相信这可能是由于中断（每10毫秒）被调用的原因。同时调用pWRSAV命令，在DSPIC24F手册中找到这个语句：103.3中断与省电指令一致。任何与执行一个PWRSAV指令相一致的中断将被推迟，直到进入休眠或空闲模式为止。特德。该设备将从休眠或空闲模式唤醒，此语句不存在于DSPIC33的手册中。然而，我不理解的是，为什么只有少数芯片具有这个错误，因为许多芯片工作正常，根本不会遇到这种错误。目前的修复方案根本不包括MyDRAM功能，但这不是最佳的功耗。这是DSIC33 FJ256GP710的已知问题吗？我必须避免使用空闲函数（但仍然可以使用瞌睡）吗？有没有确凿的方法来检验这些芯片是否可能有同样的问题，就像有些人和其他人不一样？感谢您编辑：不幸的是，张贴后，我注意到，我张贴在这个错误的区域，因为这个设备不是在开发板上。



      以下为原文

    Hello,

I am using a dspic33fj256gp710 chip to work on a project which includes a keypad. The Keypads columns are connected to PORTB. Currently I scan the keypad every 10ms, however after a random period of time (between 1 and 22 minutes) the device will only read 0's on PORTB, even though these are held high by a pull-up resistor. This indicates to the device that every button is being pressed at the same time which causes all sorts of problems.

I used my debugger to find that the Address Error Interrupt was being called just before the device ceases to function. This is done whilst the device is under Doze mode (Which I read on the Silicon Erata can cause problems if a special function register is written to, which it is during the Address Error Interrupt in order to clear the flag INTCON1bits.ADDRERR=0;).

The problem that causes the Address Error Interrupt to activate however is the Idle(); function which is called in the function below:

void myIdle(void)
{
//CLKDIVbits.DOZE=0; /* Use the 16MHz with all peripherals but Doze the cycle executions down to 16MIPS */
//CLKDIVbits.DOZE=1; /* Use the 16MHz with all peripherals but Doze the cycle executions down to 8MIPS */
//CLKDIVbits.DOZE=2; /* Use the 16MHz with all peripherals but Doze the cycle executions down to 4MIPS */
//CLKDIVbits.DOZE=3; /* Use the 16MHz with all peripherals but Doze the cycle executions down to 2MIPS */

CLKDIVbits.ROI=1; /* Automatically return to full speed on interrupt */

Nop();
CLKDIVbits.DOZEN=1; /* Doze enable must have a nop immediately before and after the instruction */
Nop();

CLKDIVbits.DOZE=4; /* Use the 16MHz with all peripherals but Doze the cycle executions down to 1MIPS */

Idle();
}

I believe that this could be due to an interrupt (every 10 ms) being called at the same time as the PWRSAV command being called, to back this up I found in the dspic24f manual the statement:

10.3.3 Interrupts Coincident with Power Save Instructions

Any interrupt that coincides with the execution of a PWRSAV instruction will be held off until entry into Sleep or Idle mode has completed. The device will then wake-up from Sleep or Idle mode

This statement does not exist in the manual for the dspic33f. What I do not understand however is why it is only a few chips that have this error as many do work fine and do not encounter this error at all. The current fix has been to not include the myIdle function at all, but this is not optimal for power consumption.

Is this a known issue for the dspic33fj256gp710?
Do I have to avoid using the Idle function (but can still use Doze)?
Is there a conclusive way to test whether these chips might have the same issue, as some do and others don't?

Thank you

EDIT: Unfortunately after posting I noticed that I posted this in the wrong area as this device is not on a development board.