1 of 1 people found this helpful
The dead-loop of the IntDefaultHandler is normally reached when something went amiss. Usual cases are
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 made a good list.
What interrupt did you end up in?
Did you make an ISR for the PWM?
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.
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..
Can we see your adc ISR code?
Pls see the below code,
#endif /* ADC_SAR_PARAMETER_IRQ_INTERRUPT_INTERRUPT_CALLBACK */
/* Place your Interrupt code here. */
/* `#START ADC_SAR_PARAMETER_IRQ_Interrupt` */
/* Read interrupt status register */
intr_status = ADC_SAR_PARAMETER_SAR_INTR_REG;
ADC_Counts = ADC_SAR_PARAMETER_GetResult16(0);
ADC_Counts = ADC_SAR_PARAMETER_GetResult16(1);
ADC_Counts = ADC_SAR_PARAMETER_GetResult16(2);
ADC_Counts = ADC_SAR_PARAMETER_GetResult16(3);
ADC_Counts = ADC_SAR_PARAMETER_GetResult16(4);
/* Clear handled interrupt */
ADC_SAR_PARAMETER_SAR_INTR_REG = intr_status;
/* `#END` */
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!
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.