ATSAMD20 and "Keep timers running in stop mode"

Go To Last Post
26 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Noob here.

 

ATSAMD20E16

Atmel studio 6.2 (I know it's old but I inherited this project).

 

My issue is I'm trying to control a buzzer with a PWM and duration timer. However, whenever I attach debugger the buzzer stops sounding. I thought it might be cus the timers stop when I attach debugger?

 

I've seen the " Keep timers running in stop mode " option mentioned in certain pages yet this isn't visible. I'm aware it's not available for all MCU's.

 

Is there a link to a page with the MCU's that support this feature? If not, anyone know a workaround?

 

Thanks

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0


The module chapter in the datasheet should describe behaviour:

 

So, you should set DBGCTRL.DBGRUN = 1 to make the timer run while the core is halted...

:: Morten

 

(yes, I work for Microchip, yes, I do this in my spare time, now stop sending PMs)

 

The postings on this site are my own and do not represent Microchip’s positions, strategies, or opinions.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Thanks for that. I set it with...

 

  RTC->MODE0.DBGCTRL.bit.DBGRUN = 1;

  RTC->MODE1.DBGCTRL.bit.DBGRUN = 1;

  RTC->MODE2.DBGCTRL.bit.DBGRUN = 1;

 

Hope that's right.

 

It hasn't solved my problem, though. I don't suppose you have any other ideas what avenues I could explore in my search for "why does debugging stop my buzzer"?

Last Edited: Tue. Jan 5, 2021 - 02:56 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

If you check the I/O view, does the bit set? If it doesn't, can you toggle it in the Ioview?

:: Morten

 

(yes, I work for Microchip, yes, I do this in my spare time, now stop sending PMs)

 

The postings on this site are my own and do not represent Microchip’s positions, strategies, or opinions.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

TedTrippin wrote:
whenever I attach debugger the buzzer stops sounding. I thought it might be cus the timers stop when I attach debugger?

Not just when you attach it.

 

As the name suggests -  Keep timers running in stop mode - it should only affect when the debugger has actually halted the CPU.

 

TedTrippin wrote:
why does debugging stop my buzzer?

You need to do some more investigation to find exactly what's going on.

 

Does it literally stop as soon as you physically connect the debugger? Or just when you start execution from the debugger? Or at a breakpoint? or ...

 

Have you used a scope on the pins - is anything happening at all?

 

Are other functions also affected?

 

Are you using a different build configuration for debugging? If so, does the buzzer ever work in that configuration - even with debugger disconnected?

Top Tips:

  1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
  2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
  3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
  4. Difference between a crystal, and a crystal oscillatorhttps://www.avrfreaks.net/comment...
  5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
  6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

TedTrippin wrote:
I set it with...

 

  RTC->MODE0.DBGCTRL.bit.DBGRUN = 1;

Are you sure that's the correct peripheral for your buzzer?

 

Each peripheral has its own DBGCTRL ...

Top Tips:

  1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
  2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
  3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
  4. Difference between a crystal, and a crystal oscillatorhttps://www.avrfreaks.net/comment...
  5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
  6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

meolsen wrote:
If you check the I/O view, does the bit set? If it doesn't, can you toggle it in the Ioview?

 

It does. However, after following this lead I've also tried setting it for the basic timers, since those are the ones I'm using. I really am a noob and I really wish I didn't have to do this!!

 

I've tried adding

    TC0->COUNT8.DBGCTRL.bit.DBGRUN = 1;
    TC1->COUNT8.DBGCTRL.bit.DBGRUN = 1;
    TC2->COUNT8.DBGCTRL.bit.DBGRUN = 1;
    TC3->COUNT8.DBGCTRL.bit.DBGRUN = 1;
    TC4->COUNT8.DBGCTRL.bit.DBGRUN = 1;
    TC5->COUNT8.DBGCTRL.bit.DBGRUN = 1;

 

But this doesn't have any affect. Also, I'm unable to change the above values in IO view.

 

If this helps, here's the timer init that control the buzzer...

 

    // TC5 Buzzer Duration

    config_tc.counter_16_bit.compare_capture_channel[0] = 2000;

    tc_init(&buzzer_duration_timer, TC5, &config_tc);

    tc_enable(&buzzer_duration_timer);

    tc_stop_counter(&buzzer_duration_timer);

 

    // TC2 Buzzer PWM

    config_tc.counter_size = TC_COUNTER_SIZE_16BIT;

    config_tc.clock_prescaler = TC_CLOCK_PRESCALER_DIV4; 

    config_tc.wave_generation = TC_WAVE_GENERATION_MATCH_FREQ; 

    config_tc.counter_16_bit.compare_capture_channel[0] = 1000;

    config_tc.pwm_channel[0].enabled = true;

    config_tc.pwm_channel[0].pin_out = PIN_PA30F_TC1_WO0;

    config_tc.pwm_channel[0].pin_mux = MUX_PA30F_TC1_WO0;

    tc_init(&buzzer_pwm_timer, TC1, &config_tc);

    tc_enable(&buzzer_pwm_timer);

    tc_stop_counter(&buzzer_pwm_timer);

 

And thanks so much for help so far.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Well, if you don't want to do it, then let the core run? Why do you need to buzzer to buzz when you halt the core?

:: Morten

 

(yes, I work for Microchip, yes, I do this in my spare time, now stop sending PMs)

 

The postings on this site are my own and do not represent Microchip’s positions, strategies, or opinions.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

This bit is not affected by a software Reset, and should not be changed by software while the TC is enabled.

So the only place you can expect to set this bit is between the tc_init and the tc_enable calls.

Also, why does it matter, are you planning to do a lot of debugging with the buzzer sounding?

/Lars

 

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

To the address the larger question, my main issue is that after detaching the debugger the buzzer no longer works. I'm trying to figure out why this happens.

 

The chip receives a command via SPI. Upon receiving the command, the timers are started. This is all that is required to get a buzz! When I debug, I can see the calls to tc_start_counter are always successful. So my question is why does the buzzer not work during, and after, debugging? I have to reset the chip for it to work again.

 

With my limited knowledge I thought that maybe the timers were being affected hence the initial question.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

:: Morten

 

(yes, I work for Microchip, yes, I do this in my spare time, now stop sending PMs)

 

The postings on this site are my own and do not represent Microchip’s positions, strategies, or opinions.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

meolsen wrote:

XY problem - Wikipedia wink

 

Indeed! Apologies for any annoyance. As a noob I'm also trying to understand how things work so as to better my understanding and ask less questions in future.

 

However, in my first post I did say that I thought this was the issue, not that it absolutely was. And in my second post I did ask for other things to check for.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Lajon wrote:

 

So the only place you can expect to set this bit is between the tc_init and the tc_enable calls.

Also, why does it matter, are you planning to do a lot of debugging with the buzzer sounding?

/Lars

 

 

 

That worked, value is now 1.

 

Unfortunately, that hasn't fixed the issue.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hihi, no need to apologize... As long as the point sticks 

:: Morten

 

(yes, I work for Microchip, yes, I do this in my spare time, now stop sending PMs)

 

The postings on this site are my own and do not represent Microchip’s positions, strategies, or opinions.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

TedTrippin wrote:
after detaching the debugger the buzzer no longer works.

TedTrippin wrote:
why does the buzzer not work during, and after, debugging?

Please clarify - is it just after detaching, or also during debugging? See #5

 

I thought that maybe the timers were being affected hence the initial question.

Also explained in #5

Top Tips:

  1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
  2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
  3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
  4. Difference between a crystal, and a crystal oscillatorhttps://www.avrfreaks.net/comment...
  5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
  6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Happens after detaching AND during debugging, even after setting dbgrun to 1.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Does it start if you attach, halt, and run again? If it doesn't then it is unrelated to DBGRUN....

:: Morten

 

(yes, I work for Microchip, yes, I do this in my spare time, now stop sending PMs)

 

The postings on this site are my own and do not represent Microchip’s positions, strategies, or opinions.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I started (F5) then stopped (ctrl shift F5) and buzzer doesn't work.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Start, Stop, Start?

 

I.e, does it (ever) resume?

:: Morten

 

(yes, I work for Microchip, yes, I do this in my spare time, now stop sending PMs)

 

The postings on this site are my own and do not represent Microchip’s positions, strategies, or opinions.

Last Edited: Tue. Jan 5, 2021 - 05:52 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Buzzer only works after a hard reset.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 1

Then, by deduction, it is not the halting itself that stops the buzzer... Because if it was, then it should resume when the core runs again... So, since it happens on the first halt, I would guess that there is some (external) side effect of halting that causes something to stop... 

:: Morten

 

(yes, I work for Microchip, yes, I do this in my spare time, now stop sending PMs)

 

The postings on this site are my own and do not represent Microchip’s positions, strategies, or opinions.

Last Edited: Tue. Jan 5, 2021 - 06:19 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

In #5, I wrote:
Does it literally stop as soon as you physically connect the debugger? Or just when you start execution from the debugger? Or at a breakpoint? or ...

Still unclear

 

also the further questions:

Have you used a scope on the pins - is anything happening at all?

 

Are other functions also affected?

 

Are you using a different build configuration for debugging? If so, does the buzzer ever work in that configuration - even with debugger disconnected?

 

 

 

Top Tips:

  1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
  2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
  3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
  4. Difference between a crystal, and a crystal oscillatorhttps://www.avrfreaks.net/comment...
  5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
  6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

TedTrippin wrote:

    config_tc.pwm_channel[0].pin_out = PIN_PA30F_TC1_WO0;

    config_tc.pwm_channel[0].pin_mux = MUX_PA30F_TC1_WO0;

That's not going to work:

 

 

EDIT 

 

This would also explain why it takes a reset to get it working again.

 

Top Tips:

  1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
  2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
  3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
  4. Difference between a crystal, and a crystal oscillatorhttps://www.avrfreaks.net/comment...
  5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
  6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...
Last Edited: Wed. Jan 6, 2021 - 10:54 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

Still unclear

 

JLink always physically attached.

When initially turned on buzzer works; I have a button that when pressed sends a command via SPI.

When pressing F5 (start debugging) buzzer no longer works.

When detaching debugger buzzer still doesn't work.

I can start debugging again and see that the SPI command is successfully received (I have a breakpoint set on the SPI callback) and still calls tc_start_counter.

 

Quote:

Are you using a different build configuration for debugging? If so, does the buzzer ever work in that configuration - even with debugger disconnected?

There are no other configurations.

 

Quote:

Are other functions also affected?

 

No other functions.

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I think your answer is in #23

 

You missed:

Have you used a scope on the pins - is anything happening at all?

I think that also would have given it away ?

Top Tips:

  1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
  2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
  3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
  4. Difference between a crystal, and a crystal oscillatorhttps://www.avrfreaks.net/comment...
  5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
  6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...
Last Edited: Wed. Jan 6, 2021 - 10:14 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

(just testing)

Top Tips:

  1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
  2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
  3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
  4. Difference between a crystal, and a crystal oscillatorhttps://www.avrfreaks.net/comment...
  5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
  6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...