I have been wrestling with the DAC on the LPC1776, and came up with some interesting, flaky behavior. I hope someone else can also reproduce it.
After hours of prying open every nook and cranny hardware and software wise, the DAC still wouldn't respond. As if nothing was driving the pin. Then out of desperation I tried configuring and running the DAC under the IRC oscillator and it worked. As soon as I changed the source clock to any other source, be it XTAL or XTAL with PLL the DAC went back into a vegetated state, no matter of the PCLKSEL divider setting (found a new entry in the errata sheet about using peripheral dividers of less than 5, but that wasn't the issue unfortunatley).
The chip otherwise works flawlessly with a 12MHz crystal and a PLL driving at 60 MHz, with EMC and SDRAM, hence the oscillator is properly configured and working.
It just occured to me to try to enable and configure the DAC before switching off of the IRC to XTAL to see if that helps. I am unable to test that at the moment, until I can get back to the office.
Can anyone else confirm the same similar behavior with the LPC part? I stripped the code bare, avoiding even the CMSIS library calls, so software shouldn't be the culprit. The code is at the end of the post.
This is really odd.
Thank you for any insights anyone can offer!
Here's the DAC code.
// Use IRC or switch to XTAL here...
// ... cut out ...
// test DAC behaviour at different peripheral divisions
LPC_SC->PCLKSEL = 4;
// direct IOCON access (CMSIS forgets the pullup is activated)
LPC_IOCON->P0_26 = _BV(16) | 0x02;
// no buffering or DMA
LPC_DAC->CR = 0;
LPC_DAC->CTRL = 0;
LPC_DAC->CNTVAL = 0;
// keep the DAC waving up and down repeatably
for(int i = 0; i < 2048; i++)
int v = abs(1024 - i);
// set output value
LPC_DAC->CR = (v & 0x3FF) << 6;
// read-out the register to see if it was set in hardware
debug("DAC: %u", LPC_DAC->CR >> 6);