• State Resolved
  • Locked Locked
  • Replies 6 replies
  • Answers 1 answer
  • Subscribers 101 subscribers
  • Views 450 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

TMDX654IDKEVM: Disable Caching leads to Firmware Crash/Stop on R5F firmware loaded via remoteproc

Johannes Zrenner
Prodigy 140 points
Part Number: TMDX654IDKEVM
Other Parts Discussed in Thread: SYSBIOS

We are currently trying to setup an example application for the R5F processor based on the IPC example code in the RTOS SDK.

With this example code we want to realize a shared memory handshake between the main application running on A53 and the application running on R5F.

This handshake works on the IPC echo_test_baremetal application on R5F when executing

CSL_armR5CacheEnableDCache(0);          /* Disable D-cache */

On our manipulated BIOS-based echo_test application calling function on R5F

CSL_armR5CacheEnableDCache(0);          /* Disable D-cache */

leads to an assert or crash, at least the application stops running after the call.

There is missing some initialization to be able to call the function without error, but i don't know what:

int main(void)

{

ipc_initSciclient();
ipc_boardInit(); /* für UART_printf */
UART_printf("UART initialized!\n");

Ipc_loadResourceTable((void*)&ti_ipc_remoteproc_ResourceTable);

UART_printf("LoadResourceTable = %p\n", &ti_ipc_remoteproc_ResourceTable);

CSL_armR5CacheEnableDCache(0);                --> Crashes

UART_printf("CSL_armR5CacheEnableDCache\n");

...

}

Maybe someone can help us what is missing to be able to disable D-cache.

Thank you very much

  • 0
    TI__Guru 50045 points

    When running in SYSBIOS, cache should be initialized by SYSBIOS. You should configure cache in SYSBIOS configuration file.

    SYSBIOS also provides Cache APIs for cache maintenance operations.

    Please refer to SYSBIOS documentation for more details.

    Regards,
    Stanley

  • 0 in reply to Stanley Liu
    Prodigy 140 points

    We use the

    PROCESSOR-SDK-LINUX-RT-AM65X 

    as an OS base to build on.

    The RTOS SDK we just installed to have example code for creating an R5F firmware. Therefor we used the IPC example code for RTOS SDK.

    Anyhow our AM65x is running on Linux and bootloaders from linux sdk.

    Regarding shared memory handling between R5F and A53 we recognized two different behaviors:

    1a) When we are using ipc_echo_test_baremetal as an basis for example code, CSL_armR5CacheEnableDCache() can be called (after (IPC_echo_test() - the given example code - was called), and our SHM handshake between R5F and A53 on address 0x81000000 works as expected. But: After Calling CSL_armR5CacheEnableDCache() UART_printf() does not print out on console anymore 

    1b) When we are not calling CSL_armR5CacheEnableDCache() then writting from A53 at 0x81000000 is not transfered or can be read from R5F (R5F still sees the initial "0"'s and not the value that the A53 has written). On the other hand UART-printf printouts work and are transferred to console.

    2.) When trying to clean the whole IPC example application code and put in only our own code  in main() our R5F application hangs or crashes when calling CSL_armR5CacheEnableDCache().

    If sysbios is the correct place to disable caching: I looked at the system-firmware-image-gen repro to find configuration possibilites about disabling DCache but did not find them:

    /ti-processor-sdk-linux-rt-am65xx-evm-07_01_00_18/board-support/k3-image-gen-2020.08b/soc/am65x/evm/board-cfg.c etc...

    In which configuration file can i enable/disable DCache? The sysbios documentation relies to the RTOS SDK as i understand.

    If there is a possibility to disable DCache by calling CSL_armR5CacheEnableDCache() in our main() of R5-application (the possibility exists, as it works when running some of the default IPC_echo_test example code before) without disabling thereby UART this would be our preffered solution as we only want to disable caching for the moment of handshake.  

  • +1 in reply to Johannes Zrenner
    TI__Guru 50045 points
    Johannes Zrenner said:
    On our manipulated BIOS-based echo_test application calling function on R5F

    I assume you are running your application on SYSBIOS based on the above statement.

    If this is correct, your R5 firmware build should have *.cfg file to configure SYSBIOS.

    I am not clear how you are building your R5 firmware.

    If you are building it from PDK in RTOS SDK, the SYSBIOS configuration file is located in pdk/packages/ti/build/am65xx/sysbios_r5f.cfg.

    In this file, you can find the cache is enabled via the below link.

    Cache.enableCache = true;

    Regards,
    Stanley

  • 0 in reply to Stanley Liu
    Prodigy 140 points

    Hello Stanley,

    thank you very much, this solved our problem. Now a memory handshake between R5F and A53 application works.

    Anyhow what i realized, since i disabled caching by setting

    Cache.enableCache = false;
    in 
    /opt/ti-processor-sdk-rtos-am65xx-evm-07_01_00_14/pdk_am65xx_07_01_00_55/packages/ti/drv/ipc/examples/common/am65xx/sysbios_r5f.cfg
    UART still works but sends data from UART_printf() blockwise, meaning not every UART_print() leads to an immediate printout (like it was before when Cache.enableCache = true), but somehow collects all data from UART_printf()-calls in an internal buffer, which is printed out from time to time maybe when the buffer is full enough.
    Do my oberservations make sense and if yes, how are UART printouts connected to caching here?
  • 0 in reply to Johannes Zrenner
    TI__Guru 50045 points

    Hi,

    There is no internal buffering and print function will write each character to UART register.

    One possibility I can think of is the program is running slower with cache disable so maybe UART_printf() is preempted by other higher priority tasks.

    Regards,
    Stanley

  • 0 in reply to Stanley Liu
    Prodigy 140 points

    Thank you very much for your explanation of the behavior, which makes sense!