Hi,
I am using the STM32F207 (Cortex-M3) device with MDK 4.50. I have an ISR function which calls isr_evt_set() to send a “Tick” event when a 1ms h/w timer tick occurs. A task calls os_evt_wait_and() and waits indefinitely for the “Tick” event. When the event arrives it does some processing and then waits for the next “Tick” event.
This all works OK until I set a breakpoint. When I hit F5 to continue code execution I get an os_error() with err_code 2 (OS_ERR_FIFO_OVF). This implies that the ISR FIFO queue buffer has overflowed. This does not happen at any other time accept when continuing after a breakpoint. I have changed the OS_FIFOSZ size from 16 to 96 but this made no difference.
I do not get this problem if I run the same code on an STR91x (ARM9).
Any ideas?
A FIFO size of 96? And an interrupt frequency of 1ms? That doesn't give you much time to spend with your code hung by the breakpoint.
My understanding is that interrupts are stopped when you hit a breakpoint. Are you saying this is not the case?
I don't know, but it really does not sound like that.
In some situations, it's good to stop interrupts. In other situations (like communication) you can't debug an application if the interrupts are stopped.
I agree that is looks like the interrupts may still be running but I can confirm that the TIM2 counter (the 1ms tick originator) stops when the breakpoint is hit. This means that even if IRQs were still active then the counter won't timeout to generate an IRQ to call isr_evt_set().
I can confirm that interrupts are definitely disabled when in Debug state. Therefore what I guess is happening is that when F5 is pressed to resume code execution following a breakpoint, then the interrupts come back to life and many 1ms interrupts occur (and many events are posted) before the debugger has resumed execution of the task that reads the events, hence the FIFO overflow. If I slow my 1ms tick to 10ms then the problem goes away. However, I need the 1ms tick so a solution would be good.
Did you check Chapter 32.16 in the ref manual? You can configure if timers are fed with a clock during a breakpoint or if they will be freezed
Hi Axel,
Yes, I did and the problems occurs regardless of how I configure the DBGMCU_APB1_FZ register (TIM2). I think it is what happens on resuming code execution that causes the problem, rather than what happens during the breakpoint. TIM2 and IRQs restart and I guess the task resumes some time later giving the IRQs enough time to fill the FIFO and cause the os_error.
hmm...you wrote you don't have this problem with a 10ms tick. can you increase the FIFO any further and check if it will work with an 1ms tick?
i just checked the OS_FIFOSZ setting and in the comments it seems like there is an 96 entry limit. but if i try 255 the source will be compiled without error and i just downloaded my code and it still is working. But OS_FIFOSZ = 256 crashes!
but maybe OS_FIFOSZ = 255 is sufficient for you?
I did try 96 but no luck. I will try the undocumented 255.
255 did not work either. I can't go any higher because of the following line in RTX_lib.c:
U8 const os_fifo_size = OS_FIFOSZ;