I am programming AD5423 DAC IC with a atmega328p-AU microcontroller with SPI, using the MCU;s internal 8-Mhz crystal. The communication protocol between the two ICs is SPI and my code works as expected (initialization, feedback, output voltage).
Now, when I switch to using the atmega328p with its external crystal (16Mhz), the AD5423's SDO (MISO line) does not always respond (it stays either 5V or 0V) and it sometimes replies correctly (aka the data I expect to see). And I do not know how to debug this behavior. The SDI/MOSI line and data are correct, its only the SDO that behaves weird.

When I switch to the external crystal these are the things I change:

  1. Clock speed variable #define F_CPU 8000000UL to #define F_CPU 16000000UL
  2. my UART speed variable: #define BRC 103 to #define BRC 207
  3. MCU LOW Fuse from 0xE2 (Internal 8Mhz) to 0xFF (ext crystal 8Mhz+) or 0xF7 (ext crystal Full swing) (I have tried both)

I have set the SPI clock/divider to be the maximum (divided by /128) to make sure that clock speed is not the issue, as I can see in AD5423's datasheet it says the SDO(MISO) has a upper speed limit: sdo limit clock

And I have checked the SPI Data lines with oscilloscope, I dont see anything weird in the slower speeds on either internal/external crystal used.

In fact, when using the 8Mhz internal clock if the MCU, I can use the fastest speed available for the SPI (clock div/2) without issue.

I use Mode 1 SPI transfer format. (From Atmega's datasheet):

SPI transfer format

To get an idea of the frequency of the SDO reply when I use the external crystal, I attach the uart/USB terminal screenshot, looks like 50% of the time the feedback/SDO works as expected:


My PCB: AD5423 with mcu

I suspect maybe because on the external crystal I don't use the capacitors on the clock pins, my MCU loses some clock signals? I cant suspect of anything else, on the next PCB version I will add capacitors to GND there and check but I doubt that.

Any ideas to debug this behavior?

  • 1
    \$\begingroup\$ Are you sure that your SPI mode matches? Why isn't CPHA=0 CPOL=1 mode better? \$\endgroup\$
    – Justme
    Commented Oct 5, 2023 at 12:48
  • 1
    \$\begingroup\$ Show a minimal code which can reproduce your issue. Chances are that the problem is not SPI itself but in handling other communication signals (controlled by your code), where some timing can change with MCU clock (for example if you have simple sequence of instructions in style set pin low, set pin high, ..., in the code) \$\endgroup\$
    – Martin
    Commented Oct 5, 2023 at 21:33
  • 1
    \$\begingroup\$ One MCU cycle at 8 MHz is 125 ns, and if you check timing table in the datasheet (page 10) there are some times with minimum value in range of 100s ns. These would be first to check correct handling. \$\endgroup\$
    – Martin
    Commented Oct 5, 2023 at 21:36
  • 1
    \$\begingroup\$ @Martin you were right. I posted the solution, but since you found it first, if you post an answer I will mark it as the correct one. \$\endgroup\$ Commented Oct 12, 2023 at 9:11
  • 1
    \$\begingroup\$ @ChristianidisVasilis cool, I am happy my comment helped and you have found the cause and solution. :) Your answer is good, +1 from me too, I do not think I can (or should try to) write any better. \$\endgroup\$
    – Martin
    Commented Oct 13, 2023 at 21:10

1 Answer 1


Okay I found out what the issue is and the solution as @Martin pointed out.

When using the external crystal, the MCU's CS/SS line would switch so fast that it violated the SPI Slave's (AD5423) minimum CS on time. Some screenshots from the oscilloscope when using external crystal:

spi with external crystal issue

And one fix is to use a delay/some nop commands between the CS/SS Set/Reset to give time for the SPI slave to register the CS bus:

SPI crystal fix


Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.