You are here

Infinite loop: IntDefaultHandler with SCB block | Cypress Semiconductor

Infinite loop: IntDefaultHandler with SCB block

Summary: 2 Replies, Latest post by Nicolas Bernardes on 13 Apr 2016 05:59 AM PDT
Verified Answers: 1
Last post
Log in to post new comments.
Nicolas Bernardes's picture
13 posts

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.

user_1377889's picture
9285 posts

Welcome in the forum!

You try to reset the interrupt with


, 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.




Nicolas Bernardes's picture
13 posts

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.


Log in to post new comments.