TMDS64EVM: Interrupt delay due to MCSPI_tranfer

Hi,

Just for a reference please go through the following FAQ:  [FAQ] SK-AM64B: MCSPI Integration Guide 

Now, coming to your query.

There are few things we have to take care about.

Kiyomasa Imaizumi said:

a 20-byte SPI transfer is performed using the MCSPI_transfer function with a timer interrupt (1 kHz).

From the statement, looks like the MCSPI Transfer will be called every 1 kHz. We need to make sure that the theoretical time taken for the MCSPI Transfer(this can be calculated keeping in mind the MCSPI data length/bytes to be transferred and the operating frequency of the MCSPI) is less than the timer interrupt number, as we need to make sure the current transfer is completed before another MCSPI Transfer is called. 

Kiyomasa Imaizumi said:

Furthermore, the processing time of MCSPI_tranfer is long.
As can be seen from the above figure, it takes nearly 30us.

To address this, I would like you to have a look at different mode of operations for MCSPI that is Interrupt, Polling and DMA and their performance numbers as well.

The different modes can be found under the following directory: SDK_INSTALL_PATH/examples/drivers/mcspi

The performance numbers for different modes can be found here: https://software-dl.ti.com/mcu-plus-sdk/esd/AM64X/11_01_00_17/exports/docs/api_guide_am64x/DATASHEET_AM243X_EVM.html#autotoc_md554

Thanks,

Vaibhav

Hello Vaibhav Kumar.

Thank you for your reply.

MCSPI is used in DMA mode.
The clock is 1.5MHz and 20 bytes are transferred.

The data transfer time is therefore 107us (=20*8/1.5e6), which is less than 1ms.

I investigated the DMA settings.
HwiP_construct is called in Udma_eventConfig, but priority=1 was set.
The 20kHz interrupt priority is 1.
This causes a delay in calling the 20kHz interrupt handler.

Therefore, it is necessary to lower the DMA interrupt priority in MCSPI.
I changed the DMA interrupt priority in MCSPI DMA mode as follows.
Is this correct?
Please let me know if there are any other ways.

-----

uint32_t intNum = 75; // DMASS0_INTAGGR_0_INTAGGR_VINTR_PEND_51
uint32_t priority = 5; // same as 1kHz interrupt
HwiP_disableInt(intNum);
HwiP_clearInt(intNum);
HwiP_setPri(intNum,priority); // change interrupt priority
HwiP_enableInt(intNum);
-----

Best regards,
Kiyomasa Imaizumi.

Hello Vaibhav Kumar.

Additional Note:
I looked at the performance numbers for the different modes.
According to the report, the throughput in DMA mode is slow. Interrupt mode is the fastest, so why is DMA mode slower?

Best regards,
Kiyomasa Imaizumi.

Hi,

Kiyomasa Imaizumi said:

The clock is 1.5MHz

I would recommend using one of the supported clock frequencies from the list shown here:  RE: [FAQ] SK-AM64B: MCSPI Integration Guide 

From your sysconfig setting, I see you have configured 3 pin mode, please set that to 4 pin mode to make sure all the 4 lines Clock, MISO, MOSI and CS is used.

Kiyomasa Imaizumi said:

Therefore, it is necessary to lower the DMA interrupt priority in MCSPI.
I changed the DMA interrupt priority in MCSPI DMA mode as follows.
Is this correct?
Please let me know if there are any other ways.

I am testing a sample application to see the best way to assign the interrupt priority. Allow me sometime on this meanwhile I wait for your actions on my above comments.

Thanks,

Vaibhav

Hi,

I have observed that the interrupt priority is set to 1 for me as well.

The place where it is called/set is as shown in the screenshot above. You might also notice that I have ran the above program in AM243-EVM but that will be not a problem as the flow is almost similar to AM64x-EVM in this case TMDS64EVM. For me as well, the interrupt number is 75 and the priority is shown as 1.

So we are on the same grounds as per the information shared by you.

I would say, the best way to set the interrupt priority is hardcoding the value to your custom value(in this case you choose 5) in the file udma_event.c itself.

So basically, hardcoding the value

hwiPrms.priority  = 5

and then rebuilding the libraries to make sure changes are saved, Then you would need to rebuild the application you are using.

Hope this helps.

Thanks,

Vaibhav

Hello Vaibhav Kumar.

Thank you for your reply.

Regarding 1.5MHz (1500000Hz), does that mean it should be set to 1.5625MHz (1562500Hz)

I'm not using CS pin so I'm deliberately using 3pin mode.

I don't want to rebuild the library so I would like to change the priority using HwiP_setPri above.
Is it ok to change the priority using HwiP_setPri as above?

Best regards,
Kiyomasa Imaizumi.

Kiyomasa Imaizumi said:

I don't want to rebuild the library so I would like to change the priority using HwiP_setPri above.
Is it ok to change the priority using HwiP_setPri as above?

Using hwi_setPri yields error?

Let me know.

Thanks,

Vaibhav

Hello Vaibhav Kumar.

HwiP_setPri does not result in an error. The priority can be changed correctly.
However, the SDK API Reference did not include the HwiP_setPri function, so I was unable to determine whether it was OK to use it.
--> I realized that it was okay to use it.

I have two more questions.

1. Please tell me more about MCSPI Transfer Mode.
I don't understand the difference between Interrupt Mode and DMA Mode.
Could you please explain in detail?
There is a description in DRIVERS_MCSPI_HLD_PAGE.html of the SDK, but it doesn't contain any detailed information.

2. Also, please tell me why there is a difference in speed between DMA mode and Interrupt mode.
And the transfer time is very slow in DMA mode.

(MCSPI driver performance in different modes:software-dl.ti.com/.../DATASHEET_AM243X_EVM.html

Best regards,

KIyomasa Imaizumi.

Hi,

Kiyomasa Imaizumi said:

HwiP_setPri does not result in an error. The priority can be changed correctly.
However, the SDK API Reference did not include the HwiP_setPri function, so I was unable to determine whether it was OK to use it.
--> I realized that it was okay to use it.

Thank you for your findings and testing the working of this API.

Kiyomasa Imaizumi said:

1. Please tell me more about MCSPI Transfer Mode.
I don't understand the difference between Interrupt Mode and DMA Mode.
Could you please explain in detail?
There is a description in DRIVERS_MCSPI_HLD_PAGE.html of the SDK, but it doesn't contain any detailed information.

2. Also, please tell me why there is a difference in speed between DMA mode and Interrupt mode.
And the transfer time is very slow in DMA mode.

I am involved in some high priority issue, so please expect delayed responses on this question.

Thanks for your patience.

Regards,

Vaibhav

Hi,

Kiyomasa Imaizumi said:

1. Please tell me more about MCSPI Transfer Mode.
I don't understand the difference between Interrupt Mode and DMA Mode.
Could you please explain in detail?
There is a description in DRIVERS_MCSPI_HLD_PAGE.html of the SDK, but it doesn't contain any detailed information.

There are 3 transfer modes, Polling, Interrupt and DMA, to read about them, please read through the following section of the AM64x TRM: 12.1.4.4.8

TRM link: https://www.ti.com/lit/ug/spruim2h/spruim2h.pdf?ts=1753872061045&ref_url=https%253A%252F%252Fwww.ti.com%252Fproduct%252FAM6442

Kiyomasa Imaizumi said:

2. Also, please tell me why there is a difference in speed between DMA mode and Interrupt mode.
And the transfer time is very slow in DMA mode.

I am going to run through these and share the updated numbers from the latest SDK using just MCSPI Loopback and MCSPI Loopback DMA application which comes along with the SDK.

Thanks,

Vaibhav

Hello Vaibhav Kumar.

Thank you for your detailed answer.

What I would like to know is why the throughput decreases in DMA mode in the throughput graph below.

Please also answer the following questions:
Regarding 1.5MHz, does that mean I should set it to 1562500Hz in sysconfig instead of 1500000Hz?

Best regards,

Kiyomasa Imaizumi.

Hi,

Kiyomasa Imaizumi said:

should set it to 1562500Hz in sysconfig instead of 1500000Hz?

Yes 1562500 should be ideal as the divider value which is acting on 50 MHz as 32, will yield 1562500. We cannot achieve 1.5 MHz as the dividers are in powers of 2.

Please let me know if upon setting 1.5 MHz are you seeing the exact frequency on the waveform? This would be a good approach to decide if 1.5 or 1.56 is the way to go.

On the throughput, I believe the time written for DMA is incorrect and I will propose to have this fixed for the next release.

Currently with the setting as mentioned in the performance datasheet linked, this is what I see.

Please note the following is in order of Interrupt, Polled and then DMA.

Thanks,

Vaibhav

Hi,

Kiyomasa Imaizumi said:

What I would like to know is why the throughput decreases in DMA mode in the throughput graph below.

I have filed a documentation bug to fix these numbers, thank you.

Regards,

Vaibhav

Hello Vaibhav Kumar.

When I set "Clock Frequency (Hz)" in sysconfig to 1500000, the actual measured clock value was 1.449MHz.
However, when I set it to 1562500 or 1562000, no clock waveform appears at all.
Why is no clock displayed?
Is it correct that 1.449MHz appears when set to 1500000?
I was expecting 1.56MHz, but that doesn't seem to be the case.
The SDK is 8.6.0.45.

Best regards,
Kiyomasa Imaizumi.

Hi Kiyomasa,

Kiyomasa Imaizumi said:

The SDK is 8.6.0.45.

There has been improvements to the MCSPI drivers along the 8 new releases of the MCU+ SDK, I would like you to have a look at the release notes: https://software-dl.ti.com/mcu-plus-sdk/esd/AM64X/11_01_00_17/exports/docs/api_guide_am64x/RELEASE_NOTES_PAGE.html

If you can test it out on the latest SDK and let me know the values that will be helpful.

Thanks,

Vaibhav

Hello Vaibhav Kumar.

I changed to the latest SDK (11_01_00_17).
Next, I also upgraded CCS (12.50 -> 12.81) and sysconfig (1.14.0 -> 1.23.0).

I imported my project (SDK 08_06_00_45) and set the properties to the latest SDK and sysconfig versions.
Then I opened example.syscfg.
I get the following warning:
Which Variant should I choose?
I don't know the difference between AM6442-D, E, and F.

I also confirmed that UDMA (PKTDMA) is being used with MCSPI.
It seems to be causing an error as shown below.

My project already uses UDMA (PKTDMA) for UART, so it cannot be used with MCSPI.

It seems difficult to build with the latest SDK.

Please let me know if there is a way to import the project correctly.

Best regards,
Kiyomasa Imaizumi.

Additional note.
I was using IPC_RPMSG in my project, but when I built ti_drivers_config.c in a new environment, the following error occurred.

---

syscfg/ti_drivers_config.c:601:88: error: expected expression
601 | rpmsgParams.vringTxBaseAddr[CSL_CORE_ID_A53SS0_0] = (uintptr_t)(&gIpcSharedMem[]);
| ^
1 error generated.

---

ti_drivers_config.c

/* Total Shared memory size used for IPC */
#define IPC_SHARED_MEM_SIZE               (0U)

/* Shared Memory Used for IPC.
*
* IMPORTANT: Make sure of below,
* - The section defined below should be placed at the exact same location in memory for all the CPUs
* - The memory should be marked as non-cached for all the CPUs
* - The section should be marked as NOLOAD in all the CPUs linker command file
*/
uint8_t gIpcSharedMem[IPC_SHARED_MEM_SIZE] __attribute__((aligned(128), section(".bss.ipc_vring_mem")));

Why is IPC_SHARED_MEM_SIZE 0?

I think this is the cause of the error.

Best regards,

Kiyomasa Imaizumi.

Additional note.

The following information was found about the ipc_rpmsg error:

e2e.ti.com/.../5031502

My project uses ipc_rpmsg to communicate between CR5 and CA53.
However, the CA53 project is built in a different environment, not CCS.
Please tell me how to resolve build errors in CCS.

Best regards,

Kiyomasa Imaizumi.

Hi,

Kiyomasa Imaizumi said:

I also confirmed that UDMA (PKTDMA) is being used with MCSPI.
It seems to be causing an error as shown below.

The error is not reproducible on my setup as I do have UART and multiple MCSPI Instances added which use the DMA mode of operation.

For the build issue, I would like you to raise another e2e, please let me know once you have created another e2e, I will assign this IPC build issue to the concerned expert.

Kiyomasa Imaizumi said:

I was using IPC_RPMSG in my project, but when I built ti_drivers_config.c in a new environment, the following error occurred.

---

syscfg/ti_drivers_config.c:601:88: error: expected expression
601 | rpmsgParams.vringTxBaseAddr[CSL_CORE_ID_A53SS0_0] = (uintptr_t)(&gIpcSharedMem[]);
| ^
1 error generated.

---

ti_drivers_config.c

Fullscreen

1

2

3

4

5

6

7

8

9

10

11

/* Total Shared memory size used for IPC */

#define IPC_SHARED_MEM_SIZE (0U)

/* Shared Memory Used for IPC.

*

* IMPORTANT: Make sure of below,

* - The section defined below should be placed at the exact same location in memory for all the CPUs

* - The memory should be marked as non-cached for all the CPUs

* - The section should be marked as NOLOAD in all the CPUs linker command file

*/

uint8_t gIpcSharedMem[IPC_SHARED_MEM_SIZE] __attribute__((aligned(128), section(".bss.ipc_vring_mem")));

XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

/* Total Shared memory size used for IPC */
#define IPC_SHARED_MEM_SIZE               (0U)

/* Shared Memory Used for IPC.
*
* IMPORTANT: Make sure of below,
* - The section defined below should be placed at the exact same location in memory for all the CPUs
* - The memory should be marked as non-cached for all the CPUs
* - The section should be marked as NOLOAD in all the CPUs linker command file
*/
uint8_t gIpcSharedMem[IPC_SHARED_MEM_SIZE] __attribute__((aligned(128), section(".bss.ipc_vring_mem")));

Why is IPC_SHARED_MEM_SIZE 0?

I think this is the cause of the error.

Thanks,

Vaibhav

Hello Vaibhav Kumar.

Regarding the MCSPI build error, I solved it by deleting the MCSPI instance in sysconfig and then reconfiguring it.

For the build issue, I raised another e2e.
Please check it.
TMDS64EVM: How to build a project created with SDK 08_06_00_45 using the latest SDK (11_01_00_17)

Best regards,

Kiyomasa Imziumi.

Hi,

I would like you to be able to proceed here once the other thread has been resolved.

Some actions pending are: 

Vaibhav Kumar said:

There has been improvements to the MCSPI drivers along the 8 new releases of the MCU+ SDK, I would like you to have a look at the release notes: https://software-dl.ti.com/mcu-plus-sdk/esd/AM64X/11_01_00_17/exports/docs/api_guide_am64x/RELEASE_NOTES_PAGE.html

If you can test it out on the latest SDK and let me know the values that will be helpful.

Thanks,

Vaibhav