Skip to main content
Associate
April 7, 2024
Question

Incorrect CPSIZE for STM32MP1 FMC

  • April 7, 2024
  • 1 reply
  • 1667 views

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!

1 reply

Erwan SZYMANSKI
Technical Moderator
April 22, 2024

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.
Associate
May 27, 2024

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?

Erwan SZYMANSKI
Technical Moderator
May 27, 2024

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.