AM5718: SPI frame loss issue

Mathieu Conq

Part Number: AM5718

Hello

We are using AM5718 in a custom application board.

The processor receives frames through SPI at a baud rate of 16Mbps (frame length is constant about 7000 bytes).

The processor is slave on the bus so we customized the spi driver and use DMA to offload data from the SPI FIFO to DDR3.

Everything works fine as long as long as we don't have much activity on the ARM side. As soon as we activate processing, we experience frame loss (some bytes are missing leading to frame being discarded).

We had the same kind of issue on a previous project (using OMAP L138) and it was fixed using internal RAM for data storage instead of external DDR.

--> Can you please provide guidance on how we can declare the OCMC in the DTS and how to allocate buffers in this memory from the driver ?

--> Can you also provide guidance on how to setup priorities on the crossbar between DMA and other peripherals ?

Thanks

Mathieu

over 9 years ago

0 Biser Gatchev-XID over 9 years ago

TI__Guru**** 393215 points

Hi,

The software team have been notified. They will respond here.

0 Yordan Kovachev over 9 years ago

TI__Guru**** 161600 points

Hi Mathieu,

--> Can you please provide guidance on how we can declare the OCMC in the DTS and how to allocate buffers in this memory from the driver ?

You can take reference from the existing idk device tree files, i.e. am571x-idk.dtsi:
/* Dual mac ethernet application node on icss2 */
pruss1_eth: pruss1_eth {
status = "okay";
compatible = "ti,am57-prueth";
pruss = <&pruss1>;
sram = <&ocmcram1>;
interrupt-parent = <&pruss1_intc>;

And the OCMCRAM is defined in dra7.dtsi:
ocmcram1: ocmcram@40300000 {
compatible = "mmio-sram";
reg = <0x40300000 0x80000>;
ranges = <0x0 0x40300000 0x80000>;
#address-cells = <1>;
#size-cells = <1>;
/*
* This is a placeholder for an optional reserved
* region for use by secure software. The size
* of this region is not known until runtime so it
* is set as zero to either be updated to reserve
* space or left unchanged to leave all SRAM for use.
* On HS parts that that require the reserved region
* either the bootloader can update the size to
* the required amount or the node can be overriden
* from the board dts file for the secure platform.
*/
sram-hs@0 {
compatible = "ti,secure-ram";
reg = <0x0 0x0>;
};
};

/*
* NOTE: ocmcram2 and ocmcram3 are not available on all
* DRA7xx and AM57xx variants. Confirm availability in
* the data manual for the exact part number in use
* before enabling these nodes in the board dts file.
*/
ocmcram2: ocmcram@40400000 {
status = "disabled";
compatible = "mmio-sram";
reg = <0x40400000 0x100000>;
ranges = <0x0 0x40400000 0x100000>;
#address-cells = <1>;
#size-cells = <1>;
};

ocmcram3: ocmcram@40500000 {
status = "disabled";
compatible = "mmio-sram";
reg = <0x40500000 0x100000>;
ranges = <0x0 0x40500000 0x100000>;
#address-cells = <1>;
#size-cells = <1>;
};

And then for buffer alocation, you can see how it is done in drivers/net/ethernet/ti/prueth.c, trace the sram_pool handle:
prueth->sram_pool = of_gen_pool_get(np, "sram", 0);

--> Can you also provide guidance on how to setup priorities on the crossbar between DMA and other peripherals ?

I don't think linux kernel sets irq or dma priorities, you have to write the DMA4_CCRi for the dedicated channel to set low or high priority.

Hope this is of help.

Best Regards,
Yordan

0 Mathieu Conq over 9 years ago in reply to Yordan Kovachev

Prodigy 100 points

Hello

We updated the dts. Buffer allocation looks OK and conversion from virtual to physical returns correctly the physical address of the SRAM.

We checked that we were able to write (from the ARM) data to the SRAM (we confirmed write is OK with readback through JTAG probe at physical address).

However when we pass the buffer to the DMA for SPI data transfer, we get the following error: "Data Access in User mode during Functional access".

Is there additional configuration to do to the OCMC controller or the L3 to authorize write from DMA ?

Thanks

Mathieu

0 Yordan Kovachev over 9 years ago in reply to Mathieu Conq

TI__Guru**** 161600 points

Hi Mathieu,

Sorry for the delayed reply.

Is there additional configuration to do to the OCMC controller or the L3 to authorize write from DMA ?

As far as I know, there shouldn't be any additional configurations.
Could you post the full error log? Maybe the bootlog (dmesg) as well.

Best Regards,
Yordan

Processors

Processors forum

AM5718: SPI frame loss issue