CY_NORETURN如何调试？

该intdefaulthandler死环通常是当事情出了差错了。通常情况是
破旧/堆栈
执行不存在的功能
寻址不存在的内存位置。
超越数组边界的书写
调试（包括读/修改变量或寄存器）可以使用你的编程设备（kitprog或miniprog3）
鲍勃



     以下为原文
  The dead-loop of the IntDefaultHandler is normally reached when something went amiss. Usual cases are
Busted/clobbered stack
Executing non-existing functions
Addressing non-existing memory location.
Writing beyond array boundaries
 
Debugging (which includes read/modify variables or registers) can be made using your programming equipment (Kitprog or Miniprog3)
 
Bob

鲍伯列了一个很好的清单。
你最后打断了什么？
你做了PWM的ISR吗？



     以下为原文
  Bob made a good list.
 
What interrupt did you end up in?
 
Did you make an ISR for the PWM?

谢谢鲍伯！！
我在使用MixPrim3，不知道在哪里寻找，知道什么导致了Nurturn！
我们可以在哪里读取皮层寄存器？我非常熟悉ST、TI和NXP芯片。
PSoC首次使用。
鲍伯，我在类似报道的问题上通过了你的其他帖子。试着看看PIN是否正在经历一个超越Vcc/VSS的浪涌。
你好啊，
当调用ADC中断时，调用堆栈总是显示未知异常。
但这只发生在负载大于150伏的情况下。
我只是想弄清楚是什么原因造成的。
当做，
尼利什



     以下为原文
  Thanks Bob!!
 
I am using Miniprog3, not sure where to look for to know what caused the NORETURN!
 
Where we can read the Cortex Registers? I am quite familiar with ST, TI and NXP chips..
 
PSOC using first time..
 
Bob, I did went through your other posts on the similar reported issue.. trying to see if pin is experiencing a surge beyond VCC/VSS.
 
Hello Arh,
 
Call stack always show unknown exception while serving ADC interrupt, when it gets stuck.
 
But this only happens if the load supply is more than 150V.
 
I just want to find out what is causing this..
 
Regards,
 
Nilesh

这些链接提供了调试项目的方法，这可能是有用的：
基于PSoC 4的串行线视图
利用JLink和GDB堆栈溢出读取皮质M0 MCU外围寄存器



     以下为原文
  These links provide ways to debug the project which may be useful:
Serial Wire View with PSoC 4
Reading peripheral register of Cortex M0 MCU using JLink and GDB - Stack Overflow

我们能看一下你的ADC ISR代码吗？



     以下为原文
  Can we see your adc ISR code?

你好，
请参阅下面的代码，
CysISR（ADCX-SARYA参数IrqqId中断）
{
γIFIFF ADCARSARIAL参数中断中断回调
AcdSARSARTIONIORQIQIQULTICATION TCONTROCALBACK（）；
Syff/*AccSARIAL参数中断中断回调*/
*把你的中断代码放在这里。*/
/*’启动AccSARIAL参数-IrqqId中断**
/*读中断状态寄存器*/
UIT32 32内状态；
内状态＝AdcSARIAL参数；
AdCl计数[0 ]＝ADCl SARYA参数EGRESULT16（0）；
AdCl计数[1 ]＝ADCl SARYA参数EGRESULT16（1）；
AdCl计数[2 ]＝ADCl SARYA参数EGRESULT16（2）；
AdCl计数[3 ]＝ADCl SARYA参数EGRESULT16（3）；
AdCl计数[4 ]＝ADCl SARYA参数EGRESULT16（4）；
/*清除处理中断*/
AdcSARIa参数SARIa InEnReg＝内状态；
AcdSARIOrthPrimeIrqQueCultBung（）；
/*’结尾’*
}



     以下为原文
  Hello,
 
Pls see the below code,
 
CY_ISR(ADC_SAR_PARAMETER_IRQ_Interrupt)
{
    #ifdef ADC_SAR_PARAMETER_IRQ_INTERRUPT_INTERRUPT_CALLBACK
        ADC_SAR_PARAMETER_IRQ_Interrupt_InterruptCallback();
    #endif /* ADC_SAR_PARAMETER_IRQ_INTERRUPT_INTERRUPT_CALLBACK */
 
 
    /*  Place your Interrupt code here. */
    /* `#START ADC_SAR_PARAMETER_IRQ_Interrupt` */
    /* Read interrupt status register */
   
        uint32 intr_status;
   
        intr_status = ADC_SAR_PARAMETER_SAR_INTR_REG;
   
        ADC_Counts[0] = ADC_SAR_PARAMETER_GetResult16(0);
        ADC_Counts[1] = ADC_SAR_PARAMETER_GetResult16(1);
        ADC_Counts[2] = ADC_SAR_PARAMETER_GetResult16(2);
        ADC_Counts[3] = ADC_SAR_PARAMETER_GetResult16(3);
        ADC_Counts[4] = ADC_SAR_PARAMETER_GetResult16(4);
       
        /* Clear handled interrupt */
        ADC_SAR_PARAMETER_SAR_INTR_REG = intr_status;
       
        ADC_SAR_PARAMETER_IRQ_ClearPending();
    /* `#END` */
}

你好，鲍伯和ARH，
这个问题一直困扰着IntDefaultHandler。
我不确定哪一个中断触发它，因为找不到诊断的方式。但从鲍伯说的话来看。看来问题的根源在硬件板上。
PSoC创建者不配置未使用的端口引脚，因此似乎是由于感应线圈的电噪声被拾起并造成破坏，我们简单地配置了所有未使用的引脚输出0的输出。问题消失了。现在运行顺利。
但是现在又有了一个新的问题，我和CyPress MyCase.问题之一是ADC通道间歇性地显示0xFFFF，ADC被配置为12位！
根据CyPress团队，这是由于PIN上存在的负噪声/尖峰，这是我无法在DSO上看到的，而特定的通道只会造成这个问题。因为噪音可能被所有其他引脚看到…？
现在，在这个问题上，我暂时忽略了ADC原始数据，如果它超过2048。想知道什么可以帮助进一步。
我认为PSoC团队应该从Studio看到CouthMax配置实用程序，这将有助于使创建者比现在更加独特！！
伙计们，非常感谢你们对我们的问题感兴趣！
当做。
尼利什



     以下为原文
  Hello Bob and Arh,
 
The issue with getting stuck into IntDefaultHandler, was addressed.
 
I am not sure which interrupt triggered it, as could not found a way to diagnose that.. but taking clue from what Bob said. It seems the root of the problem was in the hardware board.
 
PSoC creator don't configure the unused port pins, so it seem the electric noise due to induction coil was picked up and creating havoc, we simply configured all the unused pins for output with 0 output. The problem vanished.. now it runs smoothly.
 
But now there was another new issue, which I took up with Cypress MyCase. The issue was one of the ADC channel was intermittently shows 0xFFFF and the ADC is configured as 12 bit!
 
AS per Cypress team , it is due to negative noise/spike present on the pin, which I am unable to see on a DSO and that particular channel is only creating this problem. As the noise might be seen by all other pins...?
 
Now working on that issue, temporarily I am ignoring the ADC raw data if it's more than 2048. Wondering what could help further..
 
I think PSoC team should see the CubeMX configuration utility from ST. It will help making creator more unique than it is now!!
 
Guys thanks a lot you are taking interest in our problem!
 
Regards.
 
Nilesh
 
 

Nilesh，好的建议，让你从灾难当造物主版（有时组件版本）的变化：
不要修改你的中断处理程序生成的代码，虽然可以把定义和代码的标记部分。升级产生的来源可能会取代你的改变中迷失。
有两种不同的方法来规避这个问题。
习惯于“回调宏”（见创建者帮助）
使用component_startex() API，提供您自己的处理程序（使用cy_isr_proto（）和cy_isr()宏如“系统参考指南”从造物主的帮助菜单。这是我喜欢的方式´引入中断处理程序。
鲍勃



     以下为原文
  Nilesh, a good advice that keeps you from desaster when the Creator version (and sometimes the component version) changes:
Do not modify for your interrupt handlers the generated code, although it is allowed to put definitions and code into the marked sections. During an upgrade the generated sources might get replaced and your alterations are lost.
 
There are two different ways to circumvent this.
Get used to "Callback macros" (see Creator help)
Use the Component_StartEx() API and provide your own handler (using CY_ISR_PROTO () and CY_ISR() macros as shown in "System Reference Guide" from Creator help menu. This ia´s my preferred way for introducing interrupt handlers.
 
Bob