TMS320F28377D: Fapi_setActiveFlashBank execution

Johnny,

It can be interrupted.  Can you confirm that the function is executed from RAM?

Thanks and regards,
Vamsi

Hi Vamsi,

The customer initializes the flash API by using progma the code_section in TI.ramfunc and executed in LSRAM.

Also, F021_API_F2837xD_FPU32.lib is added to .cmd to execute as below pic.

If the error excludes what you said,  it can be interrupted when the function "Fapi_setActiveFlashBank is executing.

What might be the other reasons that cause the program to run to error 0x3FE493 in debug mode, and reset in non-debug mode for initial FlashAPI ? 

Though the current issue is addressed by after receiving the CAN request update instruction in the App code, then the init_FlashAPI procedure that will be executed and it is moved to the CAN Rx program (executed in ISR), the result will not be wrong.

I would still like to know the the root cause of the error as previous way.

Could you suggest me how to proceed to find the issue ?

Thanks for any help.

Johnny

Hi Vamsi,

I have looked up the FAQs you kindly provided.

I didn't see the customer's issue is similiar to the situations(can't use the Flash API) in there.

It is more like they are facing the init FlashAPI executed in different places (main loop & CAN ISR), which in the main loop it causes random errors with repeated experiments.

From above screenshot, it is set a "for loop" for a hundred times testing with executing "Fapi_setActiveFlashBank" in main loop.

It comes out 0x3fe493 error occurred after running 59 times and 17 times respectively. (random times occured error)

Also, it is tested without executing "Fapi_setActiveFlashBank" in main loop. It comes out no error after running 500 times.

Therefore, the customer have tried to execute initialization action by merely putting the code into the ISR (project only one ISR) without any other modification. It works well in repeated tests. I couldn't get the two differences in main loop and ISR execution.

May I have your comment about it ? 

Thanks for any help.

Johnny

Johnny,

Why are they calling Fapi_initializeAPI() and Fapi_setActiveFlashBank() at many places? 

ITRAP happens when there is an illegal opcode execution.  Please review their application to make sure that the flash API functions in the RAM are not overwritten (by something else) at run time by the application.

Thanks and regards,

Vamsi

Hi Vamsi,

After doing some tests, I found a possible conclusion. May I have your comment about it, confirm my idea is correct ?

Currently, it can be executed Fapi_setActiveFlashBank in main loop, but the premise is that the functions in the ISR must be placed in .TI.ramfunc.  

#pragma CODE_SECTION(function_name,".TI.ramfunc");

However, the space of .TI.func is limited, so the current code can’t put all the functions in ISR into RAM.

Therefore, the solution can only be executed by putting Fapi_setActiveFlashBank in the ISR to prevent it from being triggered by the ISR during its execution. Entering the ISR and execute the function in the flash, then an error will occur. 

Does it sound reasonable for it ?

Thanks and regards,

Johnny

Johnny,

Did you check the flash programming example in C2000Ware?  If not already, please check once.  You don't need to call Fapi_setActiveFlashBank() multiple times.  You need to call it only once.  And it should be executed from RAM (copy from flash to RAM before execution).

With the limited details on how your application firmware is architected, I am not able to comment on the ISR/loop issue that you mentioned.  In general, any time critical code/ISR is mapped to RAM for execution (load to flash) for performance benefit. 

Thanks and regards,
Vamsi

Hi Vamsi,

I have checked the example. Also, I am clear how it executed the process.

Sorry for not describing clear about why it is calling Fapi_setActiveFlashBank() multiple times with for loop.

From the customer application, the customer has written a UI with two buttons by theirselves.

The first button is to load the hex file and send the command to the DSP to update the file. The second button is to execute the action of sending the hex file to the DSP. After receiving the file, it will decode and program.

Because it is found that sometimes the first button was pressed, and the update action seemed unsuccessful after pressing the second button.

After many tests, it is found that the DSP was reset after pressing the first button.

So, it is why calling Fapi_initializeAPI() and Fapi_setActiveFlashBank() at many places in the for loop, it is all for testing to record if  the error occurs and is showned up in random.

Johhny,

Can I consider this post as closed?

Thanks and regards,
Vamsi

Hi Vamsi,

Thanks for your help. The issue is solved.

Thanks and regards,

Vamsi