比特被炒了

时间:2013-02-22 21:59:44

标签: embedded serial-port pic uart

问题:我将一个值发送到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
  • EPC注册保留9D00F228
  • SP寄存器持有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。我知道我是如何在PIC​​24中完成的(我在ASM中完全编写了该代码),但我不知道如何在PIC​​32上用C语言完成。大会没问题。我会内联它。我正在处理我没有在这里写的代码,我感谢你的答案

UART(在这种情况下为#1)会反复产生中断的最常见原因是什么?

4 个答案:

答案 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)

有三个根本原因......

  • 在UART1
  • 的初始化代码中,中断优先级设置为值6
  • 中断服务程序的第一行编码,中断优先级为5
  • UART数据的前三个字节从数据流中消失(这仍未解决)

这是导致问题的不那么明显的方式

  • 前三个字节从未出现
  • 确实出现了第四个字节
  • 中断命中(作为级别6)并调用__ISR例程
  • __ISR充当ipl5座席
  • 执行第一条指令(可能更多,我无法准确调试)
  • 第一条指令完成后,“更高”优先级6中断立即启动
  • 这又导致了同样的中断
  • 这个过程无限重复。
  • 在短期内,Stack Overflow结果

修复

确保这两行代码彼此一致......

初始化代码中的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将更加可行且速度更快。