0
\$\begingroup\$

I'm using a logic analyser to look at the MOSI, MISO, SCK and RESET lines while an ATMEGA 324PA is being flashed by at Atmel AVR MKII programmer.

The clock starts high, so that makes me think it must be CPOL = 1.

The centre of data bits coincides with the rising edge of SCK.

    -+       +-----
MOSI |       |   
     +-------+   

    -+   +---+   +-
SCK  |   ^   |   ^
     +---+   +---+

From https://upload.wikimedia.org/wikipedia/commons/6/6b/SPI_timing_diagram2.svg I think this mean CPHA=1.

Is there any documentation which confirms that CPOL=1 and CPHA=1 when programming the ATMEGA324PA? (I've searched the 600 page PDF and found nothing relating to the SPI for ISP.)

\$\endgroup\$
  • 1
    \$\begingroup\$ You mean other than the datasheet? \$\endgroup\$ – Majenko Nov 3 '16 at 12:13
  • \$\begingroup\$ @Majenko Sorry, either I, or the PDF reader's search functionality, had gone wobbly. \$\endgroup\$ – fadedbee Nov 3 '16 at 13:13
2
\$\begingroup\$

According to the datasheet:

When writing serial data to the Atmel ATmega164A/164PA/324A/324PA/644A/644PA/1284/1284P, data is clocked on the rising edge of SCK. When reading data from the ATmega164A/164PA/324A/324PA/644A/644PA/1284/1284P, data is clocked on the falling edge of SCK. See Figure 27-12 for timing details.

-- ATMega324PA Datasheet section 27.8.2

And Figure 27-12 is:

enter image description here

That looks like CPOL=0 / CPHA=0 to me (SPI Mode 0):

For CPHA=0, data are captured on the clock's rising edge (low→high transition) and data is output on a falling edge (high→low clock transition).

-- Wikipedia

Mode 0 and Mode 3 look like they should be interchangeable because they both end up clocking in on the rising edge and clocking out on the falling edge of the clock. However the difference comes when you start doing a transfer - with Mode 0 you start with a rising edge (clock in) and then get a falling edge (clock out), whereas in Mode 3 you start with a falling edge (clock out) followed by a rising edge (clock in). So although you get the same data clocked in to the chip you may find reading the data becomes offset by one bit depending on how you actually do the reading.

It may in fact be that the programmer you have is really working in Mode 0 but during times of zero activity it places the clock and data pins into a high impedance state with pullup resistors to allow bus sharing. That would look like "idle clock high" when it isn't. When programming starts it first places the pins in output mode and pulls the clock low to start the SPI sequence with a LOW clock signal (Mode 0).

\$\endgroup\$
  • \$\begingroup\$ Thanks for your answer. Your explanation of the idle clock being high due to high impedance seems correct, from the captured waveforms. It looks like an issue in the logic analyser software. It freaks out about SCK starting high and refuses to parse the SPI in mode 0. Decoding with mode 3 looks like it might be causing a one bit shift in the decoded output, as you mentioned. \$\endgroup\$ – fadedbee Nov 3 '16 at 13:09
  • \$\begingroup\$ My logic analyser does the same thing - all the pins have weak pullups (it's a cheap $5 dongle from DX). I have had instances whereby a system that wasn't working suddenly starts working when you add the analyser due to the pullups. \$\endgroup\$ – Majenko Nov 3 '16 at 13:50

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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