cancel
Showing results for 
Search instead for 
Did you mean: 

Incorrect CPSIZE for STM32MP1 FMC

Rockyaaaaa
Associate II

I am using the FMC peripheral of the STM32MP157 to access the FPGA, the FMC is configured as a Synchronous read synchronous write PSRAM. For the simplicity of the FPGA logic design I would like to have the burst reads and burst writes with CRAM page size (CPSIZE) fixed at 1024 bits.

This is the device tree configuration:

 

&fmc {
	pinctrl-names = "default", "sleep";
	pinctrl-0 = <&fmc_pins_mx>;
	pinctrl-1 = <&fmc_sleep_pins_mx>;
	status = "okay";
    psram@0,0 {
		compatible = "mtd-ram";
		reg = <0 0x00000000 0x100000>;
		bank-width = <2>;

		st,fmc2-ebi-cs-transaction-type = <8>;
		st,fmc2-ebi-cs-cclk-enable = <1>;
		st,fmc2-ebi-cs-mux-enable;
		st,fmc2-ebi-cs-buswidth = <16>;
		st,fmc2-ebi-cs-clk-period-ns = <60>;
		st,fmc2-ebi-cs-cpsize = <128>;
		st,fmc2-ebi-cs-data-latency-ns = <0>;
		st,fmc2-ebi-cs-write-bus-turnaround-ns = <0>;
		st,fmc2-ebi-cs-max-low-pulse-ns = <0>;
    };
    psram@1,0 {
		compatible = "mtd-ram";
		reg = <1 0x00000000 0x100000>;
		bank-width = <2>;

		st,fmc2-ebi-cs-transaction-type = <8>;
		st,fmc2-ebi-cs-cclk-enable = <1>;
		st,fmc2-ebi-cs-mux-enable;
		st,fmc2-ebi-cs-buswidth = <16>;
		st,fmc2-ebi-cs-clk-period-ns = <60>;
		st,fmc2-ebi-cs-cpsize = <128>;
		st,fmc2-ebi-cs-data-latency-ns = <0>;
		st,fmc2-ebi-cs-write-bus-turnaround-ns = <0>;
		st,fmc2-ebi-cs-max-low-pulse-ns = <0>;
    };
};

 

This is the part of user space program for Linux to read and write PSRAM:

 

    if ((fd1 = open("/dev/mtd6", O_SYNC | O_RDWR)) < 0)
        errmsg_die("open()");
    if (0 != lseek(fd1, 0, SEEK_SET))
        errmsg_die("lseek()");

    err = write(fd1, data, size);
    if (err < 0)
        errmsg_die("write()");
 

 

But the actual test found two problems, I got stuck for a long time completely do not know how to solve:

  1. When reading PSRAM, the length of one burst access cannot reach 1024 bits, but only 256 bits.
  2. A burst write to PSRAM can reach 1024 bits, but there is a small probability that 256 bits will be written at one time, and there will be a delay before the next round of write operation.

I suspect that this is due to some mechanism with Linux kernel or A7 core, but I am not familiar with the underlying layer at all.
I would like to ask how to solve this problem. Thanks!

3 REPLIES 3
Erwan SZYMANSKI
ST Employee

Hello @Rockyaaaaa ,
Cross-checked with FMC expert, no obvious misconfiguration seen on our side. Do you have your own driver on top of FMC stack ? Do you have a FMC register dump available somewhere ?

Kind regards,
Erwan.

In order to give better visibility on the answered topics, please click on 'Accept as Solution' on the reply which solved your issue or answered your question.

Glad to get your reply, I don't have my own FMC driver and I don't have a FMC register dump. The "mtd-ram" in the device tree is the driver that comes with the kernel. Should I dump the FMC registers using the devmem utility?

Hi @Rockyaaaaa ,
If you can get it with devmem2 yes it could be good for us to analyze this dump, as we do not see any error in your DT.

Kind regards,
Erwan.

In order to give better visibility on the answered topics, please click on 'Accept as Solution' on the reply which solved your issue or answered your question.