I made a simple circuit with a SPI master followed by a D-flip-flop. Please see attached image.

When I press a button the SPI will transmit the byte: 0xAA

I noticed that the DFF seems to latch the D input on the falling edge of the clock, which was not what I expected.

I've used DFF's often in PSoC design and they normally latch on the rising edge.

Please note I'm running at only 5 Hz SPI clock to be able watch the LEDs on the dev kit.

What's wrong here?

Regards, Tommy

Scope not inverted on other 2 channels ?

Scope trigger setup properly ?

Setup and hold on D clk OK ?

No observable glitches on D clk ?

Just thinking outloud.....

Set scope up to trigger on runt on clock and input to see if you capture anything.

Regards, Dana.

The DFF should really latch on rising edge. I would no doubt this, but look for other reasons. (Even when it would latch on rising edge, since SPI changes the data at the same moment, I would expect to see some glitches there). So the error is most likely somewhere else.

Do you get any warnings when compiling the project? How is SPI configured (mode 0)?

Dana:

Scope is not inverted on any channels.

Scope triggers on rising edge of SPI sclk ouput.

No glitches observed.

hli:

No serious warnings on compilation, just clock accuracy warnings.

SPI is configured CPHA=0 and CPOL=0

I agree with you that since the D input changes at the falling clock, it seems more like the DFF is latching on the rising edge of the clock as it should but waits for the next falling clock edge before it presents the value on Q.

Tommy

But it is the output of the DFF which changes (or should change) with the rising edge - thats the whole point of the DFF...

I will try to replicate this issue this evening, maybe I see something. Until then you might want to remove the warning about the clock accuracy - just configure the clocks so you have a slower one available derived from a crystal or the IMO (e.g. derive the master clock from IMO which gives 3MHz, and then divide it by 16). Otherwise it selects the ILO as source, which not as accurate, and which is also not synchronized to the other internal clocks.

OK, I tested it. Got the same behavior - even with a higher SPI clock derived from MASTER_CLK.

But I also have a solution for you: you need to sync the DFF clock input (I tested with syncing to BUS_CLK), the it works. See this result from the logic analyzer (the top is the SS signal used for triggering, then CLK, MOSI, and Q):

So there seems to be an issue with the DFF so that it needs a synchronized clock. Maybe you can open a support case.

hli:

Thanks a lot for your help and time. You're right. It works with a sync'ed clock.

It seems that DFF clock inputs are for system clocks only, or at least sync'ed signals.

Regards, Tommy

The DFF data sheet says nothing about being usable only with system clocks. Its also implemented (and synthesized) directly via the MacroCells in the PLD blocks. So there shouldn't be a dependency on system clocks. I suspect you hit a buig with respect to how your schematic is synthesized - something in the combination between the SPI master component and the DFF might went wrong.