AVR Freaks

No responses on this issue yet, but I've been investigating some more.  Below is sample code and a logic probe trace to show what I've observed.

// PINS:
// PA27: main clock
// PA04: trace for Event 0 (triggered by software, fires DAC START0)
// PA20: trace for Event 1 (triggered by DAC EMPTY0)
// PA02: DAC0 output
// PB09: triggers logic probe capture on program start
// PB10: hardwired to LED on SAM L22 Xplained Pro board
//
// EVENTS:
// Event channel 0: Conversion event (triggers DAC START0)
// Event channel 1: DAC.EMPTY0
//
// GCC compiler optimization set to Debugging (-Og)

#include "sam.h"

// For directly referencing a memory address
#define ADDR8(x)            (*(volatile uint8_t  *)(x))
#define ADDR16(x)           (*(volatile uint16_t *)(x))
#define ADDR32(x)           (*(volatile uint32_t *)(x))

#define REG_PORTA_PMUX1     ADDR8(&REG_PORT_PMUX0 + 1)     // PMUX address for PA02 and PA03
#define REG_PORTA_PMUX13    ADDR8(&REG_PORT_PMUX0 + 13)    // PMUX address for PA26 and PA27
#define REG_PORTA_PINCFG02  ADDR8(&REG_PORT_PINCFG0 + 2)   // PINCFG address for PA02
#define REG_PORTA_PINCFG27  ADDR8(&REG_PORT_PINCFG0 + 27)  // PINCFG address for PA27

#define DAC_MIN             ((uint16_t)0)
#define DAC_MAX             ((uint16_t)0xFFF)

#define IGNORE_BUSY 1

void pulse_led(int count);
void stall(uint32_t loops);
void DAC_Handler(void);

void init(void) {

  // Set direction on output ports
  REG_PORT_DIR0 = PORT_PA04 | PORT_PA20 | PORT_PA27;
  REG_PORT_DIR1 = PORT_PB09 | PORT_PB10;

  // Enable clock output for diagnostics
  GCLK->GENCTRL[0].reg |= GCLK_GENCTRL_OE;
  while (GCLK->SYNCBUSY.bit.GENCTRL0);                    // Wait for sync

  // Wire clock signal from GCLK_IO[0] to PA27 by selecting MUX function H.
  // Note the PMUX0 register is for PA0 and PA1, PMUX1 is for PA2 and PA3, etc.
  // The lower nibble selects the function for the even pin, and upper for the odd pin.
  REG_PORTA_PMUX13 = PORT_PMUX_PMUXO(MUX_PA27H_GCLK_IO0); // Select MUX function H for PA27 (other bits remain 0)
  REG_PORTA_PINCFG27 = PORT_PINCFG_PMUXEN;                // Enable MUX for PA27, disable pullups and input

  // Enable clock GCLK0 for event channel 0; it's used to propogate events
  // No clock is enabled for channel 1, as that one operates in ASYNC mode
  GCLK->PCHCTRL[EVSYS_GCLK_ID_0].reg = GCLK_PCHCTRL_CHEN | GCLK_PCHCTRL_GEN_GCLK0;
  while (!GCLK->PCHCTRL[EVSYS_GCLK_ID_0].bit.CHEN);       // Wait for sync

  // Wire DAC VOUT0 output to PA02 (MUX function B)
  REG_PORTA_PMUX1 = PORT_PMUX_PMUXE(MUX_PA02B_DAC_VOUT0);
  REG_PORTA_PINCFG02 = PORT_PINCFG_PMUXEN;                // Enable MUX for PA02, disable pullups and input

  // Enable clock GCLK0 for DAC
  GCLK->PCHCTRL[DAC_GCLK_ID].reg = GCLK_PCHCTRL_CHEN | GCLK_PCHCTRL_GEN_GCLK0;
  while (!GCLK->PCHCTRL[DAC_GCLK_ID].bit.CHEN);           // Wait for sync

  // Select PORT and DAC as event channel 0 users
  EVSYS->USER[EVSYS_ID_USER_DAC_START_0].reg = (0 + 1);   // DAC0 Start
  EVSYS->USER[EVSYS_ID_USER_PORT_EV_0].reg = (0 + 1);     // PORT

  // Select PORT as event channel 1 user (to monitor DAC EMPTY0 signal)
  EVSYS->USER[EVSYS_ID_USER_PORT_EV_1].reg = (1 + 1);     // Select user PORT EV1

  // Configure event channel 0.  For this example it's triggered by software.
  EVSYS->CHANNEL[0].reg =
      EVSYS_CHANNEL_ONDEMAND                              // Preferred over "always on"; see errata 14532
    | EVSYS_CHANNEL_EDGSEL_RISING_EDGE
    | EVSYS_CHANNEL_PATH_SYNCHRONOUS
    | EVSYS_CHANNEL_EVGEN(0);                             // No generator

  // Configure PORTA to pipe Event 0 signal to PA04, and Event 1 signal to PA20 (for diagnostics purposes)
  // Note "0x31" typo on datasheet pg 475; the pin numbers should be decimal
  PORT->Group[0].EVCTRL.reg =
    // Event signal 0
      PORT_EVCTRL_PORTEI0                                 // Enable event input 0
    | PORT_EVCTRL_EVACT0(0)                               // 0 = follow event, 3 = toggle on event
    | PORT_EVCTRL_PID0(PIN_PA04)                          // Tie event 0 to PA04
    // Event signal 1
    | PORT_EVCTRL_PORTEI1                                 // Enable event input 1
    | PORT_EVCTRL_EVACT1(0)                               // 0 = follow
    | PORT_EVCTRL_PID1(PIN_PA20);                         // Tie to PA20

  // Configure DAC
  DAC->CTRLB.reg = DAC_CTRLB_REFSEL_VDDANA;               // Use analog input voltage as reference
  DAC->EVCTRL.reg =
      DAC_EVCTRL_STARTEI0                                 // Events trigger start of conversion on DAC0
    | DAC_EVCTRL_EMPTYEO0;                                // Output EMPTY event when DAC0 buffer empty
  DAC->DACCTRL[0].reg =
      DAC_DACCTRL_ENABLE                                  // Enable DAC0
    | DAC_DACCTRL_CCTRL_CC1M;                             // Select current level

  // Configure event channel 1
  EVSYS->CHANNEL[1].reg =
      EVSYS_CHANNEL_ONDEMAND
    | EVSYS_CHANNEL_PATH_ASYNCHRONOUS
    | EVSYS_CHANNEL_EVGEN(EVSYS_ID_GEN_DAC_EMPTY_0);      // Generator is DAC EMPTY0
}

int main(void) {

  init();

  // 1. Enable DAC and wait for it to be ready.
  // OBSERVATION: Enabling the DAC makes its output LOW, and fires off an EMPTY event a few clock cycles later,
  // around the time the READY bit is set.
  pulse_led(1);                                           // PULSE LED ONCE to indicate we're about to enable the DAC
  DAC->CTRLA.reg = DAC_CTRLA_ENABLE;                      // Enable overall DAC module
  while (DAC->SYNCBUSY.bit.ENABLE);                       // Wait for sync after enabling DAC
  while (!DAC->STATUS.bit.READY0);                        // Await DAC0 startup (note earlier die revs should check...
                                                          // ...INTFLAG.EMPTY instead - see errata 14664 & 14678)
  pulse_led(2);                                           // PULSE LED TWICE to indicate DAC has completed startup
  stall(5);                                               // Wait for good measure, to alleviate any timing concerns

  // 2. Write first value to DATABUF0
  // OBSERVATION: Writing to DATABUF0 immediately triggers another EMPTY event
  pulse_led(1);                                           // PULSE LED ONCE; about to write to DATABUF0
  DAC->DATABUF[0].reg = DAC_MAX;
  while (DAC->SYNCBUSY.bit.DATABUF0);                     // Wait for sync
  stall(5);                                               // Wait for good measure, to alleviate any timing concerns

  // 3. Fire START0 event to begin a conversion
  while (!EVSYS->CHSTATUS.bit.USRRDY0);                   // Ensure users are ready, for good measure
  pulse_led(2);                                           // PULSE LED TWICE; about to fire event
  EVSYS->SWEVT.bit.CHANNEL0 = 1;
  stall(5);                                               // Wait for good measure, to alleviate any timing concerns

  // 4. Write second value to DATABUF0
  pulse_led(1);                                           // PULSE LED ONCE; about to write to DATABUF0
  DAC->DATABUF[0].reg = DAC_MIN;
  while (!DAC->SYNCBUSY.bit.DATABUF0);                    // Wait for sync
  stall(5);                                               // Wait for good measure, to alleviate any timing concerns

  // 5. This time, write another value to DATABUF0 to show what would happen if writes were triggered by the EMPTY0 event
  pulse_led(1);                                           // PULSE LED ONCE; about to write to DATABUF0
  DAC->DATABUF[0].reg = DAC_MAX;
#if !IGNORE_BUSY
  while (DAC->SYNCBUSY.bit.DATABUF0);                     // Wait for sync - ***THIS LINE HANGS IF ENABLED***
#endif

  // OBSERVATION: Writing to DATABUF0 again before the next START0 event does not produce the EMPTY0 event, and hangs
  // the SYNCBUSY bit high.  If the above while() line is uncommented and an attempt made to fire the next event as
  // seem below, it does not fire and instead causes an event overflow.

  stall(10);                                              // To alleviate timing concerns, and separate this section on probe
  while (!EVSYS->CHSTATUS.bit.USRRDY0);                   // Interestingly, channel reports users as ready...
  //while (EVSYS->CHSTATUS.bit.CHBUSY0);                  // ...but if this line is uncommented it hangs; the channel is busy
  pulse_led(2);                                           // PULSE LED TWICE; about to fire event
  EVSYS->SWEVT.bit.CHANNEL0 = 1;                          // 6. Attempt to fire START0 event
  if (EVSYS->INTFLAG.bit.OVR0) asm("BKPT");               // The overflow isn't immediate; execution doesn't stop here
  stall(2);
  if (EVSYS->INTFLAG.bit.OVR0) asm("BKPT");               // ***THIS LINE HALTS*** - event 0 has overflowed

  while(1);
}

void pulse_led(int count) {
  for (int i = 0; i < 2 * count; i++) {
    PORT->Group[1].OUTTGL.reg = PORT_PB10;
  }
}

void stall(uint32_t loops) {
  for (volatile int i = 0; i < loops; i++);               // volatile to avoid optimizing out
}

The fact that EMPTY0 fires as soon as you write to DATABUF0 seems (to me) to make it wholly unsuitable as a trigger for reloading the data buffer.

I also went ahead and whipped up some code to check if the behavior of the peripheral is different when it's connected to the DMA controller (trigger = DAC.EMPTY0, target = DAC.DATABUF0) and the results weren't any better.  A similar DMA example worked fine when I triggered off something else and wrote to DATA0 instead.

All my tests so far are writing all 16 bits of DATABUF0 in one go.  It occurred to me EMPTY0 might be intended for use with DMA transfer beats of one byte each.  e.g. Write to the low byte of the DATABUF0 register first, then an EMPTY0 event requests the high byte.  I mocked up some code along those lines but still wasn't able to get it to work.

My problem in all cases is that (as far as I can tell) EMPTY0 fires before the DAC is actually ready to accept new data.

Hopefully someone can explain if I'm wrong (maybe even post a small, bare-metal example showing how EMPTY0 is intended to be used), or confirm this is a bug.