This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

AM5728: Processors forum

Part Number: AM5728


Tool/software:

We have the SPI4 connected to the FPGA and I need to download its RBF file.

I carefully studied the article:
https://e2e.ti.com/support/processors-group/processors/f/processors-forum/496527/how-to-enable-mcspi-clk-in-kernel

and reproduced exactly what is written there except the MODE_MANUAL macro in pin definitions which I wasn't able to find throught the whole Linux source tree.

But the results are a bit unexpected

1. The spi4_clk pin acts as required. I see the clocks on the scope and they correspond to the defined speed. If I change the speed the clocks follow the change.|
But the data line spi4_d0 remains high all the time independently of what is transmitted.
I checked that it is connected correctly by changing MUX register values - works fine.
I checked this also by redefining this pin as GPIO - works fine.

2. An attempt to read the MCSPI4 registers fails - kernel throughs crash report. In this connection I have the following question:
The reference manual gives the following addresses of the MCSPI_CHxCONF registers:
0x4809 812C + (0x14 * x)    McSPI1
0x4809 A12C + (0x14 * x)    McSPI2
0x480B 812C + (0x14 * x)    McSPI3
0x480B A12C + (0x14 * x)    McSPI4
Is this correct? If each McSPI has its own different(!) base address why do we need the 0x14*x additional offset? And why do I have the crash on reading(!) the MCSPI registers?

Thank you very much for any hint.

  • Hi Leon,

    For question 1, I have some ideas. Recent driver added "ti,pindir-d0-out-d1-in;" property to the devicetree, and without this, d1 is configured out and d0 as in. This could explain why d0 is not transmitting. If adding in this property does not work, could you share the full logs from "dmesg"?

    For question 2, I also have some ideas. The Linux McSPI driver is smart and has some PM (power management) functionality. Most likely the McSPI hardware is in suspend mode when not in use, so hardware reads to the McSPI register would result in a crash. You can use "omapconf dump prcm" to dump the power states of all the devices and reference the TRM to see if the module is on, or attempt to read the register while there is a transaction ongoing.

    Regards,

    Takuma