a issue with SPI's CS delay control (DLYBCT)

Go To Last Post
6 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

hi,

After several days of debuging with my SPI driver for CC2420, I finally found the bug, it's a issue with CS pin timing.

CC2420's datasheet said the CS pin need to be low for at least 25ns after the last negetive edge of SCLK. And in my driver code, I used the hardware support for controlling the CS pin and didn't set any delay for DLYBCT, so the result is that CS pin is pulled up at the same time of SCLK negetive edge.

Now the problem is that if I set DLYBCT as 1, it would introduce 33 MCK delay between any transfers. This is too much for me!

I'm thinking of using software to control CS pin, but is this really the only option?

Cheng

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

anyone knows?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

In my experience the SPI CS control is a bit buggy. AFAIK the linux driver uses gpio (software control) and it would probably be the easiest solution.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

ok, good to know this. All I want is a 25ns delay, and I can only get at least 33clks...

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Yeah, the Linux driver definitely uses gpio for it's chip selecting, much less buggy. The calls through the gpio framework tend to take about the right amount of time for a nice short delay. Futher cs-to-data delays are added by doing 0-length transfers.

In your case if you need that fine a control over cs timing, I'd wire gpio chip select control in to your driver. You can then add delays as needed just by spinning away a short for loop or hitting a bunch of "asm volatile ("NOP");"s.

-S.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

ok, thanks, squidgit