问题:我将一个值发送到UART,并在另一个UART上显示空值。
---详情---
这些都是PIC处理器(PIC24和PIC32)
它们都硬接线到印刷电路板上。
他们正在通过其中的一个UART模块进行通信。
它们(表面上;根据文档)都配置为115200 bps,8-N-1
无握手,未启用CTS,未启用RTS;我只是把字节放在线上然后就可以了。
(这些是短小的4字节命令和响应,非常整齐)
PIC32的频率为80 MHz。
PIC24的F [cy] = 14745600
即,它将达到14.7456 MHz
PIC24发送四个字节(特定命令序列)
当我在UART的中断服务程序中设置一个断点时,PIC32显示空值,然后我看到前四个后(PIC32代码)断点重复点击,我继续看到空值(这很有意义)因为PIC24没有发送任何东西)
即,当没有理由时,UART似乎重复产生中断
我没有在PIC32端编写代码,而且我每天都在学习它是如何工作的。
然后我让代码运行,我不可避免地会出现在
行 52570 1D01_335C 9D01_335C _general_execption_handler sdbbp 0x0
当我到达那里时,
0080181C
9D00F228
9F8FFFA0
这就像发条一样,所以我怀疑__ISR不会停止。 MpLab告诉我这个...
432:
433: //*********************************************************//
434: void __ISR(_UART1_VECTOR, ipl5) IntUart1Handler(void) //MCU communication port
435: {
9D00F204 415DE800 rdpgpr sp,sp
9D00F208 401A7000 mfc0 k0,EPC
9D00F20C 401B6000 mfc0 k1,Status
9D00F210 27BDFF88 addiu sp,sp,-120
9D00F214 AFBA0074 sw k0,116(sp)
9D00F218 AFBB0070 sw k1,112(sp)
9D00F21C 7C1B7844 ins k1,zero,1,15
9D00F220 377B1400 ori k1,k1,0x1400
9D00F224 409B6000 mtc0 k1,Status
9D00F228 AFBF0064 sw ra,100(sp) ;<<<-------EPC register always points here
9D00F22C AFBE0060 sw s8,96(sp)
9D00F230 AFB9005C sw t9,92(sp)
9D00F234 AFB80058 sw t8,88(sp)
9D00F238 AFAF0054 sw t7,84(sp)
9D00F23C AFAE0050 sw t6,80(sp)
9D00F240 AFAD004C sw t5,76(sp)
9D00F244 AFAC0048 sw t4,72(sp)
9D00F248 AFAB0044 sw t3,68(sp)
9D00F24C AFAA0040 sw t2,64(sp)
9D00F250 AFA9003C sw t1,60(sp)
9D00F254 AFA80038 sw t0,56(sp)
9D00F258 AFA70034 sw a3,52(sp)
9D00F25C AFA60030 sw a2,48(sp)
9D00F260 AFA5002C sw a1,44(sp)
9D00F264 AFA40028 sw a0,40(sp)
9D00F268 AFA30024 sw v1,36(sp)
9D00F26C AFA20020 sw v0,32(sp)
9D00F270 AFA1001C sw at,28(sp)
9D00F274 00001012 mflo v0
9D00F278 AFA2006C sw v0,108(sp)
9D00F27C 00001810 mfhi v1
9D00F280 AFA30068 sw v1,104(sp)
9D00F284 03A0F021 addu s8,sp,zero
我仔细看一下这些数字,我看到那时候,如果我们将100(0x64)加到FFA0(SP的底部16位),我们得到0x10004,我猜也是4得多。
PIC手册DS61143E_CN第50页说这个命名法意味着,SW Store Word Mem[Rs+offset> = Rt
和其他专家告诉我,原因寄存器告诉我EXCCODE位是7,这是加载时总线异常的代码或存储。
或者,我完全在这里猜测(希望得到一些专家的知识)有些东西没有清除某些东西,我在int处理程序上遇到无限递归。
所有这一切都开始有意义了。
有人可以建议像这样的int重复击中我的最常见原因吗?
有没有人看到来自UART的假冒伪劣之间存在任何共同关系,这种关系可能会以某种方式与这种无休止的生成的int相关联?我甚至走在正确的轨道上吗?
在您的回答中,请告诉我如何从UART确认Int。我知道我是如何在PIC24中完成的(我在ASM中完全编写了该代码),但我不知道如何在PIC32上用C语言完成。大会没问题。我会内联它。我正在处理我没有在这里写的代码,我感谢你的答案
UART(在这种情况下为#1)会反复产生中断的最常见原因是什么?
答案 0 :(得分:6)
一遍又一遍地调用中断子程序的最常见原因是中断请求永远不会在例程中被确认。 你确定清除了相应的IRQ位吗?
要简化UART调试,首先应将UART连接到PC,并确保目标可以与PC进行双向通信。同时使用两个目标,除了检查带有示波器的信号之外,您无法确定问题所在。
答案 1 :(得分:6)
在许多设备上,必须明确清除中断,以防止ISR在完成时重新进入。
在大多数情况下,UART将具有指示中断源的状态位,知道可能会告诉您一些事情,但不告诉我们使您很难帮助您。您可以直接在调试器中检查UART寄存器,但是在某些器件中,读取位的行为实际上可能有点明显,在调试器中也是如此,因此请注意这种可能性(检查数据表/用户)手册)。
某些UARTS要求明确关闭发送器以停止发送空值,而其他UARTS则在数据置于tx寄存器时自动触发,并在必要的位数移出后停止。再次查看零件的数据表/手册。如果已知PIC32代码正在工作,那么因为PIC24代码可能出现这种错误,所以它似乎很合适。您可以通过使用PIC24的Tx线上的示波器来检查这一点,如果它正在发送,您将看到至少开始/停止位转换(成帧)。如果没有,那么问题可能出在PIC32端。
当你有范围外,你可以检查位时间是否正确,以及你实际上是在115200发送。很容易让时钟错误,这应该是你的第一次检查。如果波特率不正确,PIC32可能会产生帧错误中断,如果不处理,可能会无限期地持续存在。
另一种可能性是,在发送后,PIC24使线路处于“中断”状态,并且PIC32 UART正在产生“线路中断”中断。这就是为什么重要的是要查看UART状态寄存器以确定中断原因。
如您所见,有很多可能性;我想我已经涵盖了最可能的那些,但需要更多有条不紊的调试工作和信息收集。我希望我也能引导你。
答案 2 :(得分:1)
有三个根本原因......
这是导致问题的不那么明显的方式
__ISR
例程__ISR
充当ipl5
座席确保这两行代码彼此一致......
初始化代码中的IPL行,错误的方式然后是正确的
//IPC6bits.U1IP=6; //// Wrong !!! Uart 1 IPL should not be 6 !!!
IPC6bits.U1IP=5; //// Uart 1 IPL = 5 Correct way; matches __ISR
中断服务例程
void __ISR(_UART1_VECTOR, ipl5) IntUart1Handler(void) //// Operating as IPL 5
:
:
:
:
答案 3 :(得分:0)
糟糕的设计决定。如果两者都在同一块板上,那么SPI将更加可行且速度更快。