- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
We are working on a power application based on CY8C4245AXI, when the PWM starts frequently the PSoC gets stuck in,
CY_NORETURN
CY_ISR(IntDefaultHandler).
Can any one suggest, how can we debug?
We could not see a way to read internal registers of PSoC4.. can some one pls help?
Pls feel free what information is required to understand the case.
Regards,
Nilesh
Solved! Go to Solution.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Bob made a good list.
What interrupt did you end up in?
Did you make an ISR for the PWM?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
These links provide ways to debug the project which may be useful:
Reading peripheral register of Cortex M0 MCU using JLink and GDB - Stack Overflow
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Can we see your adc ISR code?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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` */
}
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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