PIC18F46K22死锁作为SPI sla

大家好，我在MSSP1上使用相关的PIC作为SPI奴隶。主机是一个MCP2210，所以我通过USB不断传输数据。然后通过SPI将接收到的数据通过MSSP2移动到外部的32 K×8位RAM单元。整个系统工作时间可变（从一小时到多小时），突然微控制器陷入死锁。我用MPLAB代码配置器在很多方面配置了时钟。它目前运行在64 MHz的HFIFToSC和软件PLL（4X），因此内部时钟是16 MHz，但它也死锁在32 MHz（8MHz HFIFTSOC）。MSSP2被用作SPI主机来驱动外部RAM存储器。它配置在模式0中，在4 MHz的SPI时钟和在脉冲的中间采样（我也尝试了在脉冲的末尾采样）。我已经配置了外部MCP2210以多种方式，从10 MHz到1 MHz的速度，并且在CS线变低之后添加了大约500个USEC的延迟。以前很高。我还应用了50字节的字节间延迟，但是这当然会在 通信中产生不希望的高延迟。总之，过了一段时间后，微控制器就被冻结了。我已经在这个问题上挣扎了大约两个月的漫长的夜晚，相信我，我已经尝试了很多组合的选择。我的PIC的修订ID是4，所以我已经检查了勘误表文档，似乎这次修订有一些关于MSSP模块的问题，但在硕士。模式（缓冲器满（BF）位或MSSP中断标志（SSPIF）位太早设置为半SCK周期），但在从属模式中没有。当触发MSSP1中断时，我总是按以下方式处理ISR：μSmiMs= SSP1BUF；/这里，“μSICMD”通过MS发送到外部RAM输出队列。SP2和/或一些数据可以从RAM输入队列SSP1BUF＝SpRMD中读取；如果（SSP1CON1BIT.WCOL）{SSP1CON1BIT.WCOL＝μRead；SSP1BUF＝S ARMMD；}（SSP1CON1BSP.SSPV）SSP1CON1BIT.SSPV=＝重置；SPI1A CurrySnInStasuSuBIT；我将MSSP1配置为从属方式：EnabelItSPI1；SETPRIORI tiONITSPI1（μSET）；//SPI从属/模式0 /样本在脉冲OpenSPI1的中间（SLVI SSON，MODE00 00，SMPMID）；你有没有经历过这方面的事情？你能告诉我是否有另一个硅错误有关这一点的PIC或有什么东西，我需要更好地配置？谢谢您！



以下为原文

Hello guys, I'm using the related PIC as SPI slave on the MSSP1. The master is a MCP2210 so I'm continuously transferring data via USB. The received data is then moved via MSSP2 to an external 32K x 8bit RAM unit via SPI.

The whole system works perfectly for a variable time (from one hour to many hours), and suddenly the microcontroller gets into deadlock.

I've configured the clock in many ways by using MPLAB Code Configurator. It is currently running using the HFINTOSC and software PLL (4x) at 64 MHz, so the internal clock is 16 MHz, but it also deadlock at 32 MHz (8MHz HFINTOSC).

The MSSP2 is used as SPI MASTER to drive the external RAM Memory. It is configured in Mode 0 with a SPI Clock at 4 MHz and sampling in the middle of the of the pulse (I've also tried sampling at the end of the pulse).

I've configured the external MCP2210 in many ways with speeds from 10 MHz to 1 MHz and adding delays of almost 500 uSec after the CS line goes LOW and before goes HIGH. I've also applied inter-byte delays of 50 uS, but this of course yields an undesirable high latency on the communication.

Anyway, after some time the Microcontroller just freeze. I've been struggling with this problem for about two months of long nights and believe me, I've tried a lot of combination of options.

The Revision ID of my PIC is 4, so I've checked the Errata Document and it seems that for this revision there are some issues regarding the MSSP module but in Master Mode (Buffer Full (BF) bit or MSSP Interrupt Flag (SSPIF) bit becomes set half SCK cycle too early.) but nothing in Slave Mode.

When the MSSP1 interrupt is triggered I always handle the ISR the following way:

_spicmd = SSP1BUF;
//Here the "_spicmd" is sent to the external RAM output Queue by using MSSP2 and
//some data could be read from the RAM input Queue
SSP1BUF = _spicmd;
if(SSP1CON1bits.WCOL)
{
SSP1CON1bits.WCOL = _RESET;
SSP1BUF = _spicmd;
}

if(SSP1CON1bits.SSPOV)
SSP1CON1bits.SSPOV = _RESET;

SPI1_Clear_Intr_Status_Bit;

I configure the MSSP1 as Slave the following way:

EnableIntSPI1;
SetPriorityIntSPI1(_SET);
//SPI Slave / Mode 0 / Sample at the middle of the pulse
OpenSPI1(SLV_SSON, MODE_00, SMPMID);

Have ever you experienced something regarding this? Could you please advise if there is another silicon bug regarding this on this reference of PIC or is there something that I need to configure better?

Thank you!