Dear Forum readers,
I have been having an issue on the Psoc5, and 5lp series parts when running in debug mode. My problem is when I have a system tic isr that goes off at 1000-10000 times per second to update counters. I am wanting to debug a separate unrelated section of code. So ill set a break point and then attempt to single step through the code I want to inspect. I need the interrupts turned on to get into this section of code. Counter counts up and then executes specific code once counters reach a specific value. So I'm in the code I need to debug. I'll set a break point and the code execution stops. Now I want to single step to the next line of code, Click the single step button and then I am in the ISR and not where I want to be. Ok, I'll click the jump out button and then I'm at the beginning of the isr again. The only way to get back to the break point is to click the play button. At this point I'm back where I started and I click the single step button and I'm in the isr again. I am hoping the part/debugger has a way of allowing me to use the single step mode while the interrupts are enabled. It seems like the internal clocks are not stopping when I have hit a break point and the debugger is not adding a fixed number clocks to the processor as I step thru each line of code. Each unique line of c code with x .asm instructions should equal y system clocks based upon the instruction in that specific line of c. Instead I get to a break point and the debugger stops and shows me where I am but the internal clocks on the processor keep running the clocks. The clock is coming from the cy_clock out of the schematic area which is tied to a isr. It does have the sync with master checked. Should I be using another kind of clock? I know I can also turn off the global interrupts manually after I hit my break point and reenable them once I am through debugging, but there has got to be a better cleaner way for this to work.
Thanks for the help!!
Yes, that issue has ben reported before, but I'm afraid it cannot get corrected.
The cause of the behaveour you have seen is hardware-dependent. Remember: When reaching a breakpoint, only the program-execution stops, the hardware is still running and may produce interrupts which are not serviced at this time.
When execution is resumed at first (of course) the interrupt becomes handled, when done the handler returns - to your breakpoint set. So it looks as if nothing has happened between. While waiting for resuming execution the next interrupt is produced... and so on.
So when single-stepping the best would be to disable the interrupts, you find a menu-button extra for this job, so you do not need to mess around in code.
yes, this is one of the issues of this IDE, but I agree that this is not much Cypress can do. The addition of having a interupt diable button on the task bar is helpful when debugging.
Great Thank you Guys!
So from what I am reading this is a silicon level issue in the processor or are the hooks in the processor to stop the processor and the debugger does not use the hooks? Bottom line, will this get addressed by Cypress in the future to be fixed or is issue going to be one of the lower level issues that wont get fixed? Im guessing this issue is in all the Psoc parts 3's-5's?
As I tried to figure out, I am sure that this issue cannot get fixed.
Hardware is still running at a breakpoint and cannot be switched orff, so generating further interrupts.
When returning (resuming) from breakpoint interrupts become active and need to be served immediately
Only thing that helps are to disable interrupts during single-step or removing / disableing current breakpoint and set another one a bitt further in code.
i am doing project on street light automation. i.e., the street light will turn on depending upon LDR and switched off during 11PM to 5 AM. In bet this if any vehicle is passed on road, the light will switch, here i am using PIR sensor for of detection of vehicle. I want to use PSoC 5 and development board.
in this i am using LDR, PIR sensor and RTC, in PSoC there are few ADC so i have to use mux, so guide me, how can i do this and programming also
I'm not sure if I'm facing the same issue with psoc3. But i can't hardly find any option to disable interrupts.
I'm not falling out of skys as the previous speaker which is obviously a little bit confused. But I think this does match original issue.
Thanks in advance.
Having said that you had on mind the label of this button 'Enable global Interrupts' as well? If this button does provide required functionallity, I'm fine with it. But i think it is a little bit confusing. Does this switch work in case in interrupt context only?
ou can only activate that switch when the program has stopped. No further interrupts will be processed except when your program runs into a CyEnableGlobalInterrupt API (macro). I am not quite sure how the exit from an interrupt handler in PSoC3 works, probably the interrupt state gets restored with a RETI instruction. So the disabling might not work as expected when the program is stopped in an interrupt handler.
Way out? Switch to the more modern PSoC5, same internal resources, but the CPU is quite more capable! The 8051 core was introduced in 1980 and has a lack of internal stack which requires the compiler to generate extra code.