2015-11-20 05:22 AM
Hi everyone,
I need some lights on the ability to switch off interrupt of TIM6 when stopping at a breakpoint. I did call the macro: __HAL_FREEZE_TIM6_DBGMCU(); But nothing, I still jump into the TIM6_IRQHandler when I step into the code. Any clue ? Thanks anyway ! (Coocox, GCC, STM32L0) #debug-breakpoint-tim2015-11-20 10:37 AM
> I did call the macro:
>
> __HAL_FREEZE_TIM6_DBGMCU(); Why? (read: what did you do to find out what to call to disable interrupts?) JW2015-11-23 10:57 PM
Hi,
Because I want to run my board in debug, so if I want to debug step by step, I need to stop getting interrupt of TIM6 otherwise, when I set a breakpoint, I will go in TIM6_IRQHandler the next step. Which I dont want. http://www.st.com/web/en/resource/technical/document/reference_manual/DM00108282.pdf section 27.9.4. page 8072015-11-24 12:02 AM
OK and does the timer run or no when you set the breakpoint (i.e. look at the timer's registers and refresh that window).
You can also read and write the DBG_APB1_FZ register directly in the debugger - if it's not in the registers window, you can do it through the memory window. JW2015-11-24 02:19 AM
the counter still runs.
I did try to set the __HAL_FREEZE_TIM6_DBGMCU(); Before the timer init, no changes I try to manually create a pointer at address 0x40015808 and write 0x10, No changes, I do not see anything written in register DBGMCU Edit : I did try to write to another register, and it works so it seams to be the problem ( was making sure the way of viewing my register ...) (So 0x10 isn't written in my register) Edit 2 : I try to manually write 1 at the address with the Memory browser tool (inside coocox ) and it's not setting it (I'm not sure I can do this like that by the way)2015-11-24 03:12 AM
It might be the debugger being overtly smart and rewriting it for you. Try a bog standard gdb instead.
JW2015-11-24 03:16 AM
It might be the debugger being overtly smart and rewriting it. You might want to search for something like a ''stop timers during debugging'' checkbox or some other similar setting. Or try a bog standard gdb instead.
Also, note that for DBG registers, ''only 32-bit access supported''. JW2015-11-25 04:41 AM
2015-11-25 05:21 AM
Ah, RCC_APB2ENR.DBGMCUEN... I should've thought about it when I noticed that - contrary to the 'F4 I am using daily - the 'F0's DBG is not part of core, rather, sits on APB2...
Thanks for coming back with the solution. JW