Skip to content

machine/samd21: implement watchdog #4907

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 1 commit into
base: dev
Choose a base branch
from

Conversation

mateusznowakdev
Copy link
Contributor

PR #3855 added watchdog implementation for some chip families, but not for SAMD21. This PR adds the missing support.

Note that SAMD21 does not have a default watchdog clock source, and none of the existing ones was a good choice:

  • GCLK0 is set to 48 MHz (DFLL48M)
  • GCLK1 and GCLK2 are set to 32 kHz (OSC32K)
  • GCLK3 is set to 8 MHz (OSC8M)

The machine.Watchdog.Configure() function will enable the last clock generator, GCLK8, set its source to OSCULP32K, and set prescaler to 32 to get nice 1.024kHz clock. This is similar to how the clock is configured for I2S peripheral -- it is configured on demand.

The remaining parts of the Configure method are the same as in SAMD51.

@deadprogram
Copy link
Member

The remaining parts of the Configure method are the same as in SAMD51.

Perhaps it would be good to put the shared parts into a single place, a new file such as machine_atsamdx_watchdog.go

Then just init the clock (as needed) in the individual files for samd21/samd51 with a new function such as initWatchdogClock().

What do you think?

@mateusznowakdev
Copy link
Contributor Author

mateusznowakdev commented May 24, 2025

I've moved the common watchdog code to machine_atsam_watchdog.go, to match naming convention for other platforms (nrf, rp2). SAMD21 works. SAMD51 compiles.

Unfortunately, the Start method can't be reused because it accesses different hardware registers.

Not sure if it makes code easier to read 😀 and there is a lot of repeated code between machine_atsamd21.go and machine_atsamd51.go anyway. We can merge this PR in its current state, and maybe someone will be interested in refactoring out the remaining common code in the future.

@deadprogram
Copy link
Member

Not sure if it makes code easier to read

I think you are correct. It was probably better before. Maybe you should remove the second commit?

@mateusznowakdev
Copy link
Contributor Author

Sure thing, done

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants