SAMD21 clock to I/O pin

[Tim23x]

Hello all,

   I'm trying to output a clock signal to an I/O pin of my ATSAMD21G, which is part of an Arduino M0 mini. I'm programming with Atmel_ICE and Atmel Studio 7. I've looked through a lot of posts but just can't seem to get it right; I've a feeling that I'm not enabling something somewhere (PM-> ?).

For example, if I try to get GCLK[0] onto PA14 (D4 on the M0 mini) I first set up the clock:

Code: [Select]

void InitClock()
{
GCLK_GENDIV_Type gendiv =
{
.bit.DIV = 1,   //Do not divide
.bit.ID = 0,     //GCLK[0]
};
GCLK->GENDIV.reg = gendiv.reg;
while (GCLK->STATUS.bit.SYNCBUSY);

GCLK_GENCTRL_Type genctrl =
{
.bit.RUNSTDBY = 0,
.bit.DIVSEL = 0,
.bit.OE = 1, //Output Enable
.bit.OOV = 0, //Output Off Value
.bit.IDC = 1, //Improve Duty Cycle
.bit.GENEN = 1, //enable this GCLK
.bit.SRC = GCLK_GENCTRL_SRC_OSC8M,
.bit.ID = 0,               //GCLK[0]
};
GCLK->GENCTRL.reg = genctrl.reg;
while (GCLK->STATUS.bit.SYNCBUSY);

GCLK_CLKCTRL_Type clkctrl =
{
.bit.CLKEN = 1,
.bit.GEN = GCLK_CLKCTRL_GEN_GCLK0; //ID of the clock
};
GCLK->CLKCTRL.reg =clkctrl.reg;
//GCLK->CLKCTRL.reg = GCLK_CLKCTRL_CLKEN | GCLK_CLKCTRL_GEN(1) | GCLK_CLKCTRL_ID_DFLL48;
while (GCLK->STATUS.bit.SYNCBUSY);
}
then I set up the ports:

Code: [Select]

void PortInit()
{
PORT->Group[0].DIRSET.reg |=  PORT_PA14;
PORT->Group[0].PINCFG[14].reg |= PORT_PINCFG_PMUXEN;
PORT->Group[0].PMUX[7].bit.PMUXE = 0x7; //Attach clock to I/O
}
Am I missing something obvious, maybe PM setting? Or just doing something stupid perhaps. Any help appreciated.

   Tim

[ataradov]

You need to use GCLK_CLKCTRL_GEN_GCLK0_Val and GCLK_GENCTRL_SRC_OSC8M_Val if you want to use this style of code. But it is much more readable to just actually write a single value to a register:

Code: [Select]

  GCLK->GENDIV.reg = GCLK_GENDIV_ID(0) | GCLK_GENDIV_DIV(1);

  GCLK->GENCTRL.reg = GCLK_GENCTRL_ID(0) | GCLK_GENCTRL_SRC_OSC8M |
      GCLK_GENCTRL_RUNSTDBY | GCLK_GENCTRL_GENEN | GCLK_GENCTRL_OE;


[Tim23x]

Hello Alex,

    Thanks a lot for your response... I can now see my clock signal on PA14.

    Best,

          Tim

[OhioStateEE]

I am not successful getting GCLK1 on pin PB23 of a SAMD21J17A.  I've programmed XMega, SAMD09 and SAMD21 chips for years, and I've often routed an internal clock to an output pin, so I know that this should be quite easy to do.  For some reason, I just can't get it to work this time.  I've used other people's code examples, which didn't work.  I also used a variation of the code provided by ataradov in this thread.  I can single-step the code with Microchip Studio debugger.  I can see output level start LOW, then go HIGH when my code sets the output level HIGH, but as soon as the MUXEN bit is set, PB23 goes low and stays low.  I've lost several days troubleshooting this problem that should be so easy to configure to use.  I hope that someone can help.   Here's my code.
   ioport_set_pin_dir(PIN_PB23, IOPORT_DIR_OUTPUT);
   ioport_set_pin_level(PIN_PB23,HIGH);      // for DEBUG only
   //PORT->Group[1].DIRSET.reg |= PORT_PB23;
   GCLK->GENDIV.reg = GCLK_GENDIV_ID(1) | GCLK_GENDIV_DIV(1);
   
   GCLK->GENCTRL.reg = GCLK_GENCTRL_ID(1) | GCLK_GENCTRL_SRC_OSC8M |
      GCLK_GENCTRL_RUNSTDBY | GCLK_GENCTRL_GENEN | GCLK_GENCTRL_OE;
    
   PORT->Group[1].PMUX[23>>1].bit.PMUXO = PORT_PMUX_PMUXO_H;  // I have also tried placing this line after the next line
   PORT->Group[1].PINCFG[23].reg |= (PORT_PINCFG_PMUXEN | PORT_PINCFG_INEN);

Best regards,
    Damon

[ataradov]

Does it work with any other GCLK_IO pin? Your code looks correct to me. Assuming you are not disabling OSC8M some place else.

I don't remember the details, but I vaguely remember that there was some documentation issue with the pin multiplexing table. You may be running into that.

[OhioStateEE]

I'll try the same code with other clocks and other pins.  OSC8M is working.  I verified that by using OSC8M as input to the I2S section "MCLK".  With MCLK_OUT enabled and MCLK_DIV=1, I could see 8 MHz out of the processor on the I2S MCLK.

[ataradov]

PB23 rings a bell specifically for some reason. But I don't have access to the JIRAs anymore, so it is hard to tell. If you verify that it is indeed works on other pins, then I would report this one more time, but it would be a known documentation issue.

[OhioStateEE]

I've verified that PB13 and PB23 work as GPIO but I can't get a clock signal out of either PB13 or PB23.  I disabled my I2S initialization and operation code to check if I could push GCLK4 out of PA10.  PA10 does show GCLK4 in that test.  It seems clear that the SAMD21 datasheet's Port Multiplexer pages have at least one error (likely two errors) regarding Clocks (MUX H), so now I'll have to test every available pin to verify that a CPU clock will indeed go out of the pin under test with I2S, SPI, and I2C also in use.  While this is definitely a big nuisance and hassle, I thank Alex very much for your assistance and memory.  So far, I've lost about 4 days chasing this weird problem.  Thank you again ,Alex, for your quick and useful replies.

[ataradov]

I don't remember there being two mistakes, but it is possible, I guess. I would report it. Multiple reports against the same issue increase the chances of it being actually fixed.

[OhioStateEE]

I ran quite a few tests today.  My results may be hard to believe, but I feel that I should report my test results.  I tested the ability to output a GCLK on various pins of the SAMD21J17A on my custom-designed board.  I did not test all pins that are listed as GCLK outputs in the datasheet's Table 7-1, column 'H'.  That's because my board uses I2S, I2C, SPI, and USB, so I didn't bother to test any pins which are in use on my board for those functions.  To configure SAMD21 clocks for my tests today, I enabled ALL GCLKs.  Since I already had code in place to set the processor to 48 MHz operation, I left that code in place, so my tests ran with the main system clock running at 48 MHz.  I tested PA14, PA15, PA22, PA23, PB13, PB14, PB15, and PB23.  Here are the raw test results:  PA14 = 48MHz .. PA15 = no clock output .. PA22 = 8MHz .. PA23=no clock output .. PB13 = no clock output .. PB14 = 48 MHz .. PB15 = no clock output .. PB23 = no clock output.  I couldn't believe the results, so I retested again.  In my tests today, which I emphasize again did not cover every pin in the 'H' column of the datasheet's Table 7-1, I saw an output GENCLK signal on even-numbered pins (e.g. PA22) but did not see any clocks output on odd-numbered pins.  This pattern made me instantly think of the MUX enable detail about "Odd" and "Even" MUX values, but I double-checked my code which set MUXEN in either the Odd or Even halves of the registers.  I am lucky that one of the available pins on my board tested "good", specifically PA22 which I've been using for I2C but I can move the I2C function to other currently unused pins.  Even though my tests today were surprising, at least now I can move ahead to revise my board so it will perform as designed.  I would be happy to make additional tests which others might suggest.

[ataradov]

The difference in frequencies would be related to the difference in clocks attached to the corresponding GCLKs.

Something is not right, there are definitely not that many mistakes in the table.

Ok, I see your mistake. You need to use PORT_PMUX_PMUXO_H_Val, not PORT_PMUX_PMUXO_H when assigning to individual bits. PORT_PMUX_PMUXO_H is pre-shifted.

[OhioStateEE]

Like you, Alex, I didn't believe that there could be that many inconsistencies with the datasheet's values.  Thanks for catching my error.  I generally prefer the simplicity of bare-metal programming but for a large project that uses DMA, I2S, I2C, USB, etc., using ASF can be a quick way to ramp-up the project ... at least it seems that way to me.

[OhioStateEE]

Alex's correction fixed the problem!  I now have GCLK1 coming out of pin PB23.  Thank you again, Alex.