TDA4VM: Customized CCS Project Loading MCU1_1 Failed

Hi Kevin,

Kevin Peng said:

Customer is using SDK8.6, and having their own CCS project based on SBL (no changes). They have already used their project to load and run all the cores successfully, except MCU1_1.

Can you please elaborate on this? What boot flow is being used by the customer? Is it the SBL boot mode or the no-boot mode?
Also, are they able to load examples on MCU2_1 with similar approach?

Regards,
Parth

We can load MCU2_1 and run successfully.Except MCU1_1. We currently verifying no boot mode, because we need to debug our application on MCU1_1 using CCS.Either we use loadSciserverFlag = 1 to let the launch.js to load PDK default MCU1_0 application or load our own MCU1_0 application run with no problems.Except when we load own MCU1_1 applications,MCU1_1 can not run.but PDK's MCU1_1 demo has no problem with this.but we don't know what is the different between our MCU1_1 applications and PDK's example.may be linker files is different? or CCS project config is wrong? or the GEL files is wrong?

Hi Jason,

Are you able to load your mcu1_1 application via SBL? Can you please share the map file of your mcu1_1 application.
Also, can you please try placing your .bss and .sramData section in __CORE_DDR_SPACE instead of OCMC_RAM and see if that works?

Regards,
Parth

no, we can't run our mcu1_1 application via SBL.our .bss and sramData is in __CORE_DDR_SPACE.

we use linker_r5f_mcu1_0_btcm_freertos.lds for mcu1_0,

linker_r5f_mcu1_1_btcm_freertos.lds for mcu1_1

6254.Archive.zip

Hi Parth,

Thanks for your reply.

Customer has put  .bss and .sramData in __CORE_DDR_SPACE, but the problem remains the same. The updated linker file & memory map are provided by Jason in the last reply. 

Please have a look if any other places might cause this issue.

Thanks a lot!

Kevin 

Hi Kevin,

Kevin Peng said:

The updated linker file & memory map are provided by Jason in the last reply. 

I just see the linker files in the zip attached, can you please share the generated map file as well?

Regards,
Parth

Also, is there any change in terms of build environment? Are you building the application using default PDK build infrastructure or are there any changes?

Hi Parth,

Customer is building through CCS, not using PDK build. However, the target compile options, arm compile flags, & arm linker flags used are the same as PDK build infrastructure.

The generated memory map for MCU1_0 is:

https://e2e.ti.com/cfs-file/__key/communityserver-discussions-components-files/791/tda4_5F00_template_5F00_mcu1_5F00_0.map

The generated memory map for mcu1_1 is:

https://e2e.ti.com/cfs-file/__key/communityserver-discussions-components-files/791/tda4_5F00_template_5F00_mcu1_5F00_1.map

Both of mcu1_0 & mcu1_1 are using BTCM, thanks a lot for your help!

Kevin

Hi Kevin,

Can you please ask them to try building the same application using PDK build environment? This will help us to narrow down the issue.

Regards,
Parth

Hi Parth,

Thanks for your suggestion!

Customer's application is quite simple like a "hello world", & they can run their application successfully by using PDK build environment.

This problem happens only using CCS to build. The reason of using ccs because it is convenient for other people to develop，do not need write makefile，and easy to debug.

Now customer could run all the cores except MCU1_1 by using CCS.

We think this problem is related to the memory allocation & the compiling environment.

Could we find some information based on the error logs below & the generated memory map attached?

The arm compiler flags used is

-DBOARD_X5_MU_SX5_A_V3 -DnBOARD_J721EXSKG -DSOC_J721E -DA72_LINUX_OS -Dj721e_evm=j721e_evm -DBUILD_MCU -DBUILD_MCU1_0 -DRTOS_ENV -DFREERTOS -DUART_DMA_ENABLE -DMCSPI_MULT_CHANNEL -DSPI_DMA_ENABLE -DUDMA_CFG_PRINT_ENABLE -DDEBUG_NETWORK -DLOG_UART=WKUP_UART0 -DnSTD_CONSOLE_OUT -gdwarf-3 -Wall -Wall -Werror=ti-pragmas -Werror=ti-macros -Werror=ti-intrinsics -Wno-extra -Wno-exceptions -Wno-parentheses-equality -Wno-unused-command-line-argument -Wno-gnu-variable-sized-type-not-at-end -Wno-unused-function -Wno-inconsistent-missing-override -Wno-address-of-packed-member -Wno-self-assign -Wno-ignored-attributes -Wno-bitfield-constant-conversion -Wno-unused-const-variable -Wno-format-security -Wno-excess-initializers -Wno-sometimes-uninitialized -Wno-empty-body -Wno-extern-initializer -Wno-absolute-value -Wno-missing-braces -Wno-ti-macros -Wno-pointer-sign -Wno-macro-redefined -Wno-main-return-type -Wno-unused-variable -Wno-unused-but-set-variable -ferror-limit=100 -fno-short-wchar -fcommon

The arm linker flags used is

-march=armv7r -mcpu=cortex-r5 -mfloat-abi=hard -mfpu=vfpv3-d16 -mlittle-endian -O0 -DBOARD_X5_MU_SX5_A_V3 -DnBOARD_J721EXSKG -DSOC_J721E -DA72_LINUX_OS -Dj721e_evm=j721e_evm -DBUILD_MCU -DBUILD_MCU1_0 -DRTOS_ENV -DFREERTOS -DUART_DMA_ENABLE -DMCSPI_MULT_CHANNEL -DSPI_DMA_ENABLE -DUDMA_CFG_PRINT_ENABLE -DDEBUG_NETWORK -DLOG_UART=WKUP_UART0 -DnSTD_CONSOLE_OUT -gdwarf-3 -Wall -Werror=ti-pragmas -Werror=ti-macros -Werror=ti-intrinsics -Wno-extra -Wno-exceptions -Wno-parentheses-equality -Wno-unused-command-line-argument -Wno-gnu-variable-sized-type-not-at-end -Wno-unused-function -Wno-inconsistent-missing-override -Wno-address-of-packed-member -Wno-self-assign -Wno-ignored-attributes -Wno-bitfield-constant-conversion -Wno-unused-const-variable -Wno-format-security -Wno-excess-initializers -Wno-sometimes-uninitialized -Wno-empty-body -Wno-extern-initializer -Wno-absolute-value -Wno-missing-braces -Wno-ti-macros -Wno-pointer-sign -Wno-macro-redefined -Wno-main-return-type -Wno-unused-variable -Wno-unused-but-set-variable -ferror-limit=100 -fno-short-wchar -fcommon -Wl,--reread_libs -Wl,--diag_suppress=10063 -Wl,--diag_suppress=10068 -Wl,--diag_suppress=10083 -Wl,--diag_warning=225 -Wl,--display_error_number -Wl,--xml_link_info="tda4_template_linkInfo.xml" -Wl,--use_memcpy=fast -Wl,--use_memset=fast,--rom_model

Thanks a lot!

Kevin

Hi Kevin,

CCS based builds are not supported on J721e rtos SDKs and recommendation would be for customers to use the SDK's makefile based build system. This will help in SDK migrations as well in future. We do not recommend to use CCS builds as it has to be maintained separately and adapted release on release.

Kevin Peng said:

This problem happens only using CCS to build. The reason of using ccs because it is convenient for other people to develop，do not need write makefile，and easy to debug.

You can always use debug profile option while building using PDK builds if debugging is a concern.

Regards,
Parth

Hi Parth,

Thanks for your information. I will suggest customer use PDK build in the future.

I have tested running the "ipc_echo_test_mcu1_1_release_strip.xer5f" which is built in our default SDK8.6 at RTOS_SDK/targetfs/lib/firmware/pdk-ipc/ folder. After a Happy Debugging shown on the CCS12.0, I connected the MCU1_1 target and then load this default file to MCU1_1, the same error shows below.

If I load other default mcu1_1 xer5f files like the ones located in SBL such as sbl_baremental_boot_test_j721e_evm_mcu1_1TestApp_release.xer5f, there is no such errors, so may I know if there is any requirement to load mcu1_1 properly on CCS?

Kind Regards,

Kevin

Hi Kevin,

I am able to reproduce this issue on my end, I can see the similar behavior as you. For some reason, for MCU1_1 ACTM > 2KB is not accessible, due to which we are not able to load via CCS. I am checking this further, will get back with details on this.

Regards,
Parth

Hi Kevin,

Is this issue still open? I believe we closed it in an offline discussion right?

Regards,
Parth