AM2612: AM2612 Flash API, timeout is 1ms, but my customer needs to use 1us

Rio Chan

Genius 16140 points

Part Number: AM2612
Other Parts Discussed in Thread: SYSCONFIG

Hi Champs:

#1. Please see the below API.

#2. The timeout is 1ms.

But my cust needs the timeout value precision unit to be as 1us.

Reason: He is making a Motor 1 Axis spin applicaiton.

So, he needs to access the SPI Nand flash as quick as he can.

He neesd the None-Blocking mode, how to make this API as 1 "us" timeout?

BR Rio

3 months ago

0 Shaunak Deshpande 3 months ago

TI__Mastermind 23782 points

Hi Rio,

When calling this API from application, you can just pass the timeout in terms of system ticks, based on what frequency the system is running at, you can convert 1us to systicks.

If you want, you can make it completely non-blocking by passing "MCSPI_NO_WAIT" as timeout value. For example, if system tick frequency is 200Mhz, then 1us would be 200 clock cycles, so timeout can be passed as 200.

Regards,
Shaunak

0 Rio Chan 3 months ago in reply to Shaunak Deshpande

TI__Genius 16140 points

Hi Shaunak:

May you demo how is the code looks like?

You mean: When calling the MCSPI_lld_write, the parameter "timeout" can be set as "MCSPI_NO_WAIT"

BR Rio

0 Rio Chan 3 months ago in reply to Rio Chan

TI__Genius 16140 points

Hi Shaunak:

MCSPI_NO_WAIT = 0, this API will return Error.

Can you fix it?

BR Rio

0 Rio Chan 3 months ago in reply to Rio Chan

TI__Genius 16140 points

Hi .

Cust RD and me, we 100% confirmed if we set those 2 API with MCSPI_NO_WAIT, the API will return -3 error, Plz fix this.

MCSPI_lld_read + MCSPI_lld_writeMCSPI_NO_WAIT (0)，those 2 API will return MCSPI_INVALID_PARAM (-3) !!.

BR Rio

0 Shaunak Deshpande 3 months ago in reply to Rio Chan

TI__Mastermind 23782 points

Hi Rio,

I have filed an internal bug (https://jira.itg.ti.com/browse/MCUSDK-15463) , the SDK team and I will look into it.

Regards,
Shaunak

0 Rio Chan 3 months ago in reply to Shaunak Deshpande

TI__Genius 16140 points

Hi Shaunak:

Plz provide the Temp Fix before the next official SDK fix.

We need to fix this asap since their PCB will be back in 2 weeks.

BR Rio

0 Shaunak Deshpande 3 months ago in reply to Rio Chan

TI__Mastermind 23782 points

Hi Rio,

I have started an internal discussion with the dev team to get this prioritized. I will keep you updated.

Regards,
Shaunak

0 Shaunak Deshpande 2 months ago in reply to Shaunak Deshpande

TI__Mastermind 23782 points

Hi Rio,

Will customer be okay in using an interrupt based approach for non-blocking SPI transactions?

Regards,
Shaunak

0 Rio Chan 2 months ago in reply to Shaunak Deshpande

TI__Genius 16140 points

Hi Shaunak:

#1. I have checked the Jira, there is no any progress there. May you speed up the fix?

#2. Isn't the solution for this issue an Non-blocking SPI?

Please have the fix asap, thanks.

BR Rio

0 Shaunak Deshpande 2 months ago in reply to Rio Chan

TI__Mastermind 23782 points

Hi Rio,

One way to go around this is, configure the MCSPI driver to run in interrupt mode (you can refer the example.syscfg of the mcspi_loopback_interrupt_lld example).

Here we use a non-blocking interrupt way, and you can pass a MCSPI_NO_WAIT timeout to the interrupt mode APIs. So when the MCSPI transfers are called from the interrupt configuration use the below APIs:

MCSPI_lld_readWriteIntr() or MCSPI_lld_readIntr() or MCSPI_lld_writeIntr(), This will give you a non-blocking way (application won't be blocked, and when the transfers are complete, you will enter your callback ISR defined in the sysconfig.

To quickly test, you can modify the mcspi_loopback_interrupt_lld example and modify the timeout variable to MCSPI_NO_WAIT, rebuild and test the SDK example.

Regards,
Shaunak

0 Rio Chan 2 months ago in reply to Shaunak Deshpande

TI__Genius 16140 points

Hi Shaunak:

I will treat this as a temp fix.

But my Cust needs this for Official / normal fix.

Reason:

Several Cust RD needs to learn this temp fix, it's not okay for them.

BR Rio

0 Shaunak Deshpande 2 months ago in reply to Rio Chan

TI__Mastermind 23782 points

Hi Rio,

This fix is not a workaround, this is an actual fix. Polling APIs cannot be considered to be "non-blocking". For a non-blocking transfer we need to use interrupt mode, in which if NO_WAIT Is passed, we would get to error in return.

Regards,
Shaunak

0 Rio Chan 2 months ago in reply to Shaunak Deshpande

TI__Genius 16140 points

==>if NO_WAIT Is passed, we would get to error in return.

Hi Shaunak:

May I confirm if your statement here has the typo?

It should be:

==>if NO_WAIT Is passed, we would get "no" error in return.

plz correct me if I'm wrong.

BR Rio

0 Shaunak Deshpande 2 months ago in reply to Rio Chan

TI__Mastermind 23782 points

Hey Rio,

Sorry for the typo:

- When NO_WAIT Is passed in interrupt mode -> no invalid params error code

- When NO_WAIT is passed in polling mode (blocking) -> invalid params error code returned.

Hope this clears confusion.

Regards,
Shaunak

0 Rio Chan 2 months ago in reply to Shaunak Deshpande

TI__Genius 16140 points

Hi Shaunak:

Good, and thanks, I will close this if my cust agreed.

BR Rio

0 Rio Chan 2 months ago in reply to Rio Chan

TI__Genius 16140 points

Hi Shaunak:

My cust agreed to close.

BR Rio

Arm-based microcontrollers

Arm-based microcontrollers forum

AM2612: AM2612 Flash API, timeout is 1ms, but my customer needs to use 1us