TDA4VM: operation result of the push stack instruction did not match the register value

Hi,

Are you seeing this issue with any example in PDK? If yes, can you please share the example you are using and share the instructions to observe this issue on our end.
Also, please mention the SDK version you are using.

Regards,
Parth

Hi

The app i use is my own elf generated by K3ImageGen.sh and this elf can run normally by SPL startup. My pdk version is pdk_jacinto_08_02_00_21, SBL is sbl_mmcsd_img_mcu1_0 compiled in this pdk.

I have tried two examples in PDK with the same SBL img.

1.ocmc_memory_benchmarking_app_freertos can run normally

2.csl_uart_test_app runs away in __mpu_init() when a subfunction returns

By comparison, the assembly of __mpu_init() and its subfunction in ocmc_memory_benchmarking_app_freertos is the same  as csl_uart_test_app. 

By comparison, the assembly of __mpu_init() and its subfunction in ocmc_memory_benchmarking_app_freertos is different with my own elf.

ocmc_memory_benchmarking_app_freertos is compiled in linux by ti-cgt-arm_20.2.0.LTS in ti-processor-sdk-rtos-j721e-evm-08_02_00_05.

My own elf uses ETAS Autosar and compile in windows by ti-cgt-arm_20.2.5.LTS(only can use this version because ETAS required). 

My compiler options is as blow:

assembly of subfunction CSL_armR5StartupCacheInvalidateAllCache() in ocmc_memory_benchmarking_app_freertos

assembly of subfunction CSL_armR5StartupCacheInvalidateAllCache() in my own elf

Because the assembly instruction is different, i don't know whether you can observe this issue in csl_uart_test_app.

Although the assembly instruction is different, my own elf can run normally by SPL startup. It demonstrates that the assembly itself is correct. So what is different between SPL and SBL that can lead to error of PUSH instruction?

I try to fix the wrong value in stack by PUSH artificially, it can return correctly.

Hi,

?? ? said:

ocmc_memory_benchmarking_app_freertos is compiled in linux by ti-cgt-arm_20.2.0.LTS in ti-processor-sdk-rtos-j721e-evm-08_02_00_05.

From SDK 8.2 we are using TI ARM CLANG compiler and ti-cgt-arm_20.2.0.LTS is not supported in 8.2. Are you able to build with ti-cgt-arm_20.2.0.LTS on SDK 8.2 without any changes?

Also, can you try building ocmc_memory_benchmarking_app_freertos with the same version of tool chain with which you are building your own custom app and see if it is running into issues as well?

Regards,
Parth 

Hi,

I didn't change anything in pdk_jacinto_08_02_00_21 and just run "make -s all BOARD=j721e_evm CORE=mcu1_0" in PDK_INSTALL_DIR/packages/ti/build. The examples ocmc_memory_benchmarking_app_freertos and csl_uart_test_app are built by this way. So, as you say, they should be compiled by TI ARM CLANG compiler. I don' t know SDK 8.2 uses TI ARM CLANG compiler and ti-cgt-arm_20.2.0.LTS is not supported before your reply.

The version of tool chain with my own custom app is not support in SDK 8.2 and i don't know how to modify the SDK to support this version.

I think all above is not import. My question is single assembly instruction "PUSH" executes exception in app by SBL startup. But this app run normally by SPL startup. This is already a comparison. As to the difference of the assembly of __mpu_init() and its subfunction between examples in SDK and my own app, it may be beacuse the compiler is different. Two compiler achieve assembly code from different files and source code is different.

In a word, why assembly instruction "PUSH" executes exception by SBL startup? Which can influence?

Hi,

?? ? said:

In a word, why assembly instruction "PUSH" executes exception by SBL startup? Which can influence?

This could be due to some fault. I won't be able to say for sure till I am able to reproduce this error on my end.

?? ? said:

2.csl_uart_test_app runs away in __mpu_init() when a subfunction returns

I tried this on my end. I ran csl_uart_test_app with SBL, but it seems to be working fine without any issues. Can you please share the exact steps you are doing to observe this error with csl_uart_test_app?

Regards,
Parth

Hi,

The version is pdk_jacinto_08_02_00_21,(1. add a delay at the begin of main() of SBL to let me have time to connect debugger. 2. compile SBL using SKIP_MCU_RESET)

1. change path to PDK_INSTALL_DIR/packages/ti/build, run "make -s all BOARD=j721e_evm CORE=mcu1_0" to generate csl_uart_test_app_mcu1_0_release.appimage and run "make -s sbl_mmcsd_img BOARD=j721e_evm CORE=mcu1_0" to generate sbl_mmcsd_img_mcu1_0_release.tiimage

2. make SD card follow the steps in https://software-dl.ti.com/jacinto7/esd/processor-sdk-rtos-jacinto7/07_03_00_07/exports/docs/psdk_rtos/docs/user_guide/out_of_box_j721e.html

3. copy the sbl image to the SD card and rename it to tiboot3.bin, copy the generated application image to the SD card and rename it to app, copy the tifs.bin in <PDK>/packages/ti/drv/sciclient/soc/V1 to the SD card

4. when run to CSL_armR5StartupGetCpuID( CSL_ArmR5CPUInfo *cpuInfo )  in __mpu_init(), assembly instruction "STMDB" executes exception and  the value in stack is not the same as in registers, so the software runs to "LDMIA" will break down.

5. if i use ocmc_memory_benchmarking_app_freertos to replace csl_uart_test_app without any other change, it run normally.

Hi,

I tried the same steps as yours but I am still not getting the issue with CSL uart test app. Can you please share your binaries. I'll try those binaries.
Meanwhile, please try the binaries created at my end and if you face the issue with those. 

Binaries.zip

Connect to CCS, load the symbols and then locate the source file. The change the ccsHalt from 1 to 0 and then you can single step through it.

Regards,
Parth

Hi,

here is my binaries

ocmc_memory_benchmarking_app_freertos.zip

csl_uart_test_app.zip

mmcsd.zip

?? ? said:

The version is pdk_jacinto_08_02_00_21,(1. add a delay at the begin of main() of SBL to let me have time to connect debugger. 2. compile SBL using SKIP_MCU_RESET)

How much delay did you keep here?

Do you see this issue when you are not single stepping and run at once? I mean, if you run without any breakpoint or delay, are you able to jump to main of the app? Or are you able to see logs from the app?

I use your binarie and get the same issue.

I directly run software for a while and then stop it, i find it has been broken. It can not jump to main of the app.

?? ? said:

I directly run software for a while and then stop it, i find it has been broken. It can not jump to main of the app.

Why are you stopping the app here?

Also, I tried your binaries and did not see any issues. I copied your mmcsd SBL and csl uart app to SD card. Ran it directly without connecting to the debugger. And I can see the logs from the test.

I have a few questions here:
1) Are you using a custom board or is it TI EVM.
2) Have you tried running this csl uart test app without any changes, with the out of box SBL and without connecting to the debugger? If not, can you please try it once and share the observations?
3) Can you also increase the log level for the SBL and share the logs?

Regards,
Parth

Why are you stopping the app here?

I directly run software for a while with no breakpoints and then press the break button. It stops at function undefInstructionExptnHandler() and cpu mode is UND. Then, i debug the software and find the assembly instruction "STMDB" executes exception.

1) Are you using a custom board or is it TI EVM.

I am using a hardware board designed by my company.
2) Have you tried running this csl uart test app without any changes, with the out of box SBL and without connecting to the debugger? If not, can you please try it once and share the observations?

I try it and can only see the log as bellow. No print of uart test in app. 

3) Can you also increase the log level for the SBL and share the logs?

I think log level just affects SBL, the error is in _c_int00 of app. SBL can work normally.

?? ? said:

I am using a hardware board designed by my company.

Do you have TI-EVM with you? Can you try running the example on EVM once?

Regards,
Parth

Sorry, I don't have TI-EVM.

Hi,

Unlocking this thread. Is this issue still open? If yes, can you please share the schematics diagram of your board showing UART connections?
Also, which UART instance are you using for your console?

Are you seeing this issue with all the tests on your board?

Regards,
Parth