Infinite loop: IntDefaultHandler with SCB block

Tip / Sign in to post questions, reply, level up, and achieve exciting badges. Know more

cross mob
lock attach
Attachments are accessible only for community members.
Anonymous
Not applicable

Dear all,

   

I hope you guys can help me with this. I am having a problem with the PSoC 4 (CY84245AXI-483) code that it keeps entering in a infinite loop inside a interruption handler (CY_ISR(IntDefaultHandler)).

   

The project consists in an End Point XBEE node that has a user Button (BTN) connected to it. In the StartUp of the device, if the button is pressed, it executes the XBEE configuration (network, IOs,etc.). Later this button can only be used to send a dummy data to the Network coordinator to allow proper addressing of all nodes. This action is handled by an rising edge interrupt routine that enters in critical region (disabling all interrupts) while the user is pressing the button to send the dummy data.

   

The first time that the system runs (button pressed) all the configuration works perfectly and the dummy data runs once. Then the PSoC enters in the nonsense infinite loop.

   

I read here in the forum and also in the PSoC Developer forum that it is something related to interruption handlers declaration. But I could not find any issue related to that in my current code.

   

 

   

Any Help will be greatly appreciated.

   

ps.: The XBEE communication is all handled in API mode.

   

Find the project bundle attached.

0 Likes
4 Replies
Bob_Marlowe
Level 10
Level 10
First like given 50 questions asked 10 questions asked

Welcome in the forum!

   

You try to reset the interrupt with

   

    BTNConfig_ClearInterrupt();

   


, but BTNConfig is your I/O-pin component which does not generate an interrupt by itself.

   

You may use isr_BTNConfig_ClearPending() which would clear your interrupt.

   

Furthermore you might get a lot of pulses. When you get one when releasing the button you do not clear the interrupt.

   

Local variables do not need to be declared as "volatile", only globals need that.

   

It is not a good idea to wait for several seconds with all interrupts switched off. When the project is expanded to do more jobs this might stall the system. I would suggest you to change the logic to using a flag and poll for it in main().

   

When debugging  it may look as if you "hang" in an interrupt handler, do not single-step. Use breakpoints to stop your program.

   

 

   

Bob

0 Likes
Anonymous
Not applicable

Dear Bob,

   

Thank you very much for your help and advices. I did the BTNConfig_ClearInterrupt() and the isr_BTNConfig_ClearPending() before but it did not work out, so I remove it (not the best idea - I will put it back as I know i may cause some issue in the future).

   

Regarding the wait inside the interrupt, I will try to implement it in the main routine setting just a flag inside the interruption. I know it is a better coding to do so.

   

I opened a Case along with Cypress regarding this same issue. And apparently it is working now. The problem was within the XBEE_Reconditec.c file in the XBEE_RxDataHandler function. While in the IDLE state, the RxBufferIndex kept incrementing for no reason (even if there is no data in the SCB Rx Buffer). Therefore, I managed to move the Packet->Data[RxBufferIndex++] to inside the if(ReceivedByte == XBEE_StartDelimiter) and also moved the entire switch statement to a new if(XBEE_UART_SpiUartGetRxBufferSize() != 0u) as there is no need to go for the switch if there is no data in the Rx Buffer.

   

 

   

I will perform these changes and I hope the code runs smooth!

   

Thank you again for your help.

   

Regards

0 Likes
lock attach
Attachments are accessible only for community members.
Anonymous
Not applicable

Hi Bob, I have a similar problem in my code, I have to disable and enable continuously some interrupts and for some reason the code jump to the infinite loop CY_ISR(IntDefaultHandler) in Cm3Start.c.

   

In the class Interrupt.c and Interrupt.h I have the manage to start, stop and execute all the interrupts of my application, do you have any idea how to fix this problem??, I attach the workspace and the interest project name is Calima2.

   

Thanks in advance.

0 Likes
Bob_Marlowe
Level 10
Level 10
First like given 50 questions asked 10 questions asked

Quite a complex project! I would try using / interpreting the call stack to see where the program flow came from. The interrupt is usually called in case of an error as addressing memory that doesn't exist, executing invalid instructions and other mishaps. Usually caused by bad pointers, clobbered stack or arrays out of bounds. Does your debug variables show any hint?

   

 

   

Bob

0 Likes