Help with DSPI on MCF5485

[raulen]

Hello everybody,

I have got two devices that use the DSPI depending on the chip select, a FRAM and a RTC.

I have been looking at the DSPI source code, but I don't understand how to fix these devices on the DSPI driver.

Moreover, each device works with a different configuration (baudrate).

Could anyone explain me how to proceed in order to use the devices thru the DSPI?

Best regards,

Raúl

[raulen]

I got to attach the RTC to the DSPI and now I can't the read the date and time from /sys. However, the values are invalid (no sense, for example: day: 45, hour: 33...). I guess I have a configuration or registers problem. I will have to go in deep of the source code.

But I have doubts regarding how to register my FRAM device in the DSPI. There are some examples with flash adn eeprom, but anyone with nvram or fram. Does anyone have an example of nvram/fram through SPI  to understand how it works?

[aeg]

Hi Raul,

I've done a couple of things with the 5475's DSPI and know it fairly well at this point.

Are you using Linux to do this? If so, what version? Or more importantly, are you using the 2.6.10 dspi driver or the new spi interface (in 2.6.25)?

Please, describe your setup in a bit more detail. I assume you've checked your clocks, chip selects etc etc. so you know that the hardware is OK.

Best,

Andreas

[raulen]

Hello Andreas,

I am using the Linux version 2.6.25 with the new dspi driver.

I am sure the hardware is OK, because we are also using VxWorks in the same board and the DSPI devices works perfectly. Moreover I can see the signals through the oscilloscope (chip select, clock).

I added my configuration board in the arch/asm-m68k/coldfire/m547x_8x-devices.c file:

static struct coldfire_dspi_chip hua_chip_info = {
        .bits_per_word = 8,
        .mode = SPI_MODE_3,
};

static struct spi_board_info spi_board_info[] = {
        {
                .modalias = "ds3234",
                .bus_num = 1,
                .chip_select = 0,
                .controller_data = &hua_chip_info,
                .max_speed_hz = 100000,
        },
        {
                .modalias = "fram",
                .bus_num = 1,
                .chip_select = 2,
                .controller_data = &hua_chip_info,
                .platform_data = &fram_data,
        }

};

I initialized the dspi registers in the function m547x_8x_spi_init  of the same file: GPIO_PAR_DSPI, DSPI_DSR, DSPI_DCMR, DSPI_DRSER.

Then I have a file for the RTC device (ds3234.c, I adapted this driver from the kernel 2.6.28) and a file for the FRAM (based on an EEPROM, although with lots of changes).

Currently I can see the both devices on /sys, so I guess they are correctly attached. Problems:

- RTC: it is possible I have a speed and configuration problem. I enabled the debug messages and when I read the date and time the status and configuration registers always read 0xff. However if I turn down the speed (through the br and pbr fileds of the coldfire_dspi_chip structure), the status and configuration register seem OK, but the driver hangs the kernel after the function dspi_setup_chip.

- FRAM: I have a "fram" file that I use as the file to read and write the memory. When I try to read the file, the kernel crashes.

Maybe I am forgetting doing something regarding the configuration that I did not know I had to do. Please, correct me if you detect something wrong or weird.

Thanks for your help!

Raúl

[aeg]

Hi Raul,

I've noticed a couple of things with the 2.6.25 dspi. I have an audio chip a with similar speed as your rtc and it looked to me like CS was deactivated between bytes even though they were part of the same message/transfer.

Can you check to see if this occurs on your end? In other words, do you have more than two bytes in your transfers and can you check if CS is deactivated during this time?

I have a DMA enabled version of the spi driver that behaves a little differently but it is still not working 100%.

Let me know how it goes,

Andreas

[raulen]

Hi again,

You're right, Andreas. According the "MCF5485 Device Errata", the DSPI has a bug. If the transmit FIFO queue underflows during a continuous transfer, then the CS is deactivated. You have to avoid to leave the queue empty. The easy way if you don't need a fast spi is turn down the speed. We configured the DSPI around 100 KHz. Fortunately our spi applications doesn't need many accesses and so the speed is not very important.

I realized the behaviour you say if I did not configure the speed. Then I always read 0xff. It means, the device was not working properly. But if I configure a slow speed (50-100 KHz), then the RTC register are configured right, but the kernel hangs. It must be hanged in the dspi_interrupt routine, but I don't know why.

It is not easy to understand all about the worqueues and so...

Any idea why the interrupt routine could be hanged? 

Regarding the another device, I will get worried about the crash when the RTC works fine.

Best regards,

Raúl

[aeg]

Raul,

Too bad you found out about it this way.

I'll try to upload my dspi change which allows the dma to take care of the transfers (and controlling the CS better).

Meanwhile, you could try to control CS yourself. Check the of the mcf547x-548x-devices.c file. There is a function that'll be called when spi requests the bus.

Set your CS to be GPIO instead of spi controlled.

Oh, try this with only one spi device for now. My dspi patch also includes exclusive access to the spi bus.

This will take me a few days. I'm in the midst of a release here and have less than 12 hours to complete my work.

Best,

Andreas

[raulen]

Hi Andreas,

I enabled the debug message. If I try to read the time I get:

 -sh-2.05b# cat sys/bus/spi/devices/spi1.0/rtc\:rtc0/time
[transfer] 
[pump_messages] 
[pump_transfers] 
[dspi_setup_chip] 
mcr: 0x80050c00, ctar: 0x3e00000a

The last line is a line I added with the values of the MCR and CTAR0 register in dspi_setup_chip.

The system is waiting foreover. It seems waiting for a task or an interrupt. After some time, the following message appears periodically:

 INFO: task cat:752 blocked for more than 120 seconds.
"echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
cat           D 001e8d44     0   752    751

I think I am not having a CS problem (not 100% sure). I can see the CS in the oscilloscope. It is activated when I read the time and deactivated after some time, but I don't know if it is deactivated too soon.

I guess the function to control the CS you mentioned is coldfire_spi_cs_control. Anyway, I am not sure if the CS problem is happening. 

Best,

Raúl

[aeg]

Hey Raul,

Sorry for being a bit absent lately.

Anyway, I have worked some more on the spi portion and I don't think it will do it for my application. I will continue to use my own implementation instead.

However, a few things to try on your end would be to verify the clock rate. On your oscilloscope, trigger on CS and look at the clocks. Measure the frequency and see if it is valid.

The 2.6.25 version I have will not calculate max_speed_hz properly if I don't set .pbr=0 and .dbr=0 in the chip_info section.

Also, are you implementing the RTC?

I can send you a patch of the spi for your reference.

Best,

Andreas

[raulen]

Hi Andreas,

I have to do many things on our custom board, so regarding the dspi I have been waiting for your news.

I would appreciate if you send your spi patch as a reference.

The RTC I am using is the ds3234. I searched it and I found the implementation in the 2.6.28 kernel version. I took it and modified a pair of things to compile. I guess it works properly.

Best regards,

Raúl

[aeg]

Hi Raul,

give this patch a try. Apply it to the drivers/spi folder. I also included my devices file just in case.

In order to get exclusive access to the bus, call spi_lock_bus before any spi commands are sent.

Let me know how/if it works.

-A

[raulen]

Hello Andreas,

Last week I was occupied fixing another device on my board, but I have already returned back to the spi.

I applied the patch and adapted my m547x_8x-devices.c file. Just a pair of things:

- Now it is supposed I have to modify my spi device driver (rtc) with lock_bus & unlock_bus before/after any spi commands, don't I?  

- When I try to compile with your patch, I get an error due to the lack of lock_bus and unlock_bus in the spi_master structure. This structure is defined in /include/linux/spi/spi.h, so I have to declare these function pointers, am I right?

Regards,

Raúl

[aeg]

Hi Raul,

you're correct regarding the spi_master. If you haven't already fixed it, I've included the header to this message.

Yes, you should use lock_bus and unlock_bus when using spi commands. And this goes for all spi transfers in other drivers as well.

Let me know how it goes.

Best,

Andreas

[raulen]

Hi Andreas,

I have already applied the patch, added the lock & unlock_bus in the spi.h and used the CS locks before/after the functions of the spi slave devices.

I am testing it with the RTC. The reading of the date/time and the device registers work apparently. However, when I tried to write the RTC registers, it fails. The CS line is active (low-level) during the necessary period of time, but the set of registers doesn't work.

I think the problem could be in the way the dspi shifts from the FIFO to the device, although I am a bit lost about why it doesn't work.

The writing and reading of the registers are basically the same, just I have to add 0x80 in the address field in order to the spi knows it is a command of writing.

Did you have similar problems?  

Best,

Raúl

Message Edited by raulen on 2009-03-17 09:01 AM

[raulen]

Hello,

I haven't got to write registers of my spi slave devices yet.

But I found out another problem. Another of my spi slave is a memory (fram). If I try to read more than 16 bytes (DSPI_FIFO_SIZE), the dspi driver reads wrong. Only the first 16 bytes are correct, the rest are 0xff (that is false).

It has to be fixed, but I am still on it...

[aeg]

Hey Raul,

does your device require a constant CS throughout the transaction? I had major issues with the CS being deasserted/reasserted when sending more than n bytes.

If you're willing to change approach, I can give you my other spi driver, but you have to change your entire slave interface.

-A

[raulen]

Hi Andreas,

if you don't mind, let me see what you have done with your spi driver.

I think the issue is to try to avoid having the Tx FIFO empty. So, the CS will be never deactivated during the transmission.

In the dspi.c code, the only enabled interrupt is the EOQFE. One solution could be to enable the TCFE interrupt and to put a new byte in the FIFO by means of the interrupt routine. What do you think?

Another question, what size does the DSPI_FIFO? 16 or 4?

Best,

Raúl Moreno