AnsweredAssumed Answered

MCF547x/8x DSPI and 16-bit transfers

Question asked by Petteri Matilainen on Jan 30, 2014



I'm trying to interface an RTC chip into my MCF5485 board, It's on the SPI bus, on chip select 0. The RTC chip is an RTC9701JE, for which there's a driver in the kernel: rtc-r9701. The problem is that the chip doesn't initialize. I have observed the traffic on the SPI bus using a logic analyzer and from there I can see that the SPI deasserts the chip select between bytes even though it should transfer 16bits at a time. The RTC chip expects a 16bit transfer and a continuous chip select for the entire 16bits. Currently the system transfers 8bits, deasserts the CS and after 30 ms asserts it again and tries to read 8bits but obviously can't get any usable data in. I'm using latest Freescale's BSP to build the kernel and root file system.


The question is: how do I modify the driver so that the chip select is continuously asserted during transfers? I have set 16bit transfers (devices.c) but still it transfers 8bits at a time?


I have modified devices.c to load the driver, like so:


#ifdef CONFIG_RTC_DRV_R9701

static struct coldfire_dspi_chip rtc_spi_chip_info = {

    .bits_per_word = 16,

    .mode = SPI_MODE_3,

    .pcsis = 0x00, // All chip selects active-high (idle-state low = 0x00)

    .dbr = 0,

    .pbr = 3,

    .br = 6,

    .pcssck = 2,

    .pasc = 2,

    .pdt = 2,

    .cssck = 2,

    .asc = 1,

    .dt = 1,




#if defined(CONFIG_RTC_DRV_R9701)


      .modalias = "rtc-r9701",

      .max_speed_hz = 1000000,

      .bus_num = 1,

      .chip_select = 0,

      .controller_data = &rtc_spi_chip_info,




The driver loads but the probe fails as it tries to read a register in the RTC and can't get the correct data. I have tried to set the CONT bit in the DTFR register but I needed to write some code into the mcf_dspi.c and it didn't seem to work. No errors in the compilation either.


Attached are a couple of pics and also the drivers rtc-r9701.c and dspi_mcf.c.


transfer1.png: this is the first byte transferred. The write is correct, 0x87.


transfer2.png: after 33 ms it tries to read back (writes 0x00) but fails to read any valid data.


transfer3.png: this is how it should go. Write 0x87 and then during the next 8 clocks the data is read from DI (0x20 which is correct). The difference here is that the chip select is NOT deasserted betweeen bytes. For this picture I added a 0x00 byte to transfer in addition to 0x87. The problem is still that after 33 ms (chip select down) it tries to read during 8 clocks and so ignores the already received correct byte. I've checked the FIFO, it reads 0xF020. 0xF0 is the bogus byte and 0x20 the correct one. So the received byte is there, the system just ignores it. Thanks in advance!

Original Attachment has been moved to:

Original Attachment has been moved to: