AM6442: Query Regarding Flashing Bootloader Images on Custom AM6442 Board

Hi Ganesh,

I assume you are using a different OSPI Flash than the one used on the EVM, Please check this guide on adding support on custom flash device: https://software-dl.ti.com/mcu-plus-sdk/esd/AM64X/11_01_00_17/exports/docs/api_guide_am64x/CUSTOM_FLASH_SUPPORT_GUIDE.html

Best regards,

Meet.

Hi Thakar,

Thank you for your response — much appreciated.

I’d like to share the current objective and seek your inputs on a couple of points:

Objective:
We are attempting to flash the binary to the EMMC and boot the core, similar to the process followed on the evaluation board. However, our custom board uses a different EMMC part number.

Queries:

a) Are there any configuration changes or additional steps required due to the EMMC part number difference? We are currently unable to flash the image or boot successfully from EMMC.

b) For debugging the code using CCS IDE with an XDS debugger, is there any dependency on OSPI? If so, could you please clarify the requirements?

Looking forward to your guidance on these points at your earliest convenience.

Thanks and regards

Ganesh Pawar

Hi Ganesh,

ganesh pawar said:

a) Are there any configuration changes or additional steps required due to the EMMC part number difference? We are currently unable to flash the image or boot successfully from EMMC.

There is no such additional step required for EMMC.

Does your custom board have both EMMC and OSPI installed? 

Please note that default_sbl_null is to flash the SBL NULL to OSPI and not EMMC, are you now able to successfully flash to the OSPI at least after my suggestion in the previous response.

What issue you are facing with flashing EMMC currently? Please share the flashing logs for this.

ganesh pawar said:

b) For debugging the code using CCS IDE with an XDS debugger, is there any dependency on OSPI? If so, could you please clarify the requirements?

There aren't any particular dependencies, are you facing any issues with the same?

Best Regards,

Meet.

Hi Thakar,

Let me walk you through the steps we've taken so far:

Meet Thakar said:

Does your custom board have both EMMC and OSPI installed? 

Yes, our custom board includes both:

• EMMC: SFEM032GB2ED1TO-A-5E-111-STD
• OSPI NOR Flash: IS25WP512MG-RHLA2

However, as per our current requirement, booting from EMMC (HS image) is the priority. Therefore, we have not followed the OSPI-related steps mentioned in your previous response.

Meet Thakar said:

There aren't any particular dependencies, are you facing any issues with the same?

Yes, we are currently unable to flash the image to the Cortex-M4F core using CCS IDE, regardless of the boot mode selected (UART, OSPI, or DEVBOOT), we had validated in Evaluation kit.

 Observation:

When connecting the JTAG (XDS110 via 20-pin connector) to the device, we encounter the following log output:

Log observed while flashing the image in EMMC mode

Log observed while flashing the image in xSPI mode /Uart mode/DevBoot mode.

Could you please advise on:

1. Any known issues or dependencies that could block JTAG access or image flashing in this setup.
2. If no configuration changes are required when using a different EMMC part number, what could be preventing the detection of the EMMC image or the flashing of the combined HS-FS application image (including Cortex-A, Cortex-M4, and Cortex-R5 cores) as per the sbl_emmc flashing guide.  

Looking forward to your insights.

Thanks and Regards

Ganesh Pawar

This just indicates the SoC/M4 core is not initialized yet. There are several ways to initialize the SoC, please refer to this guide: https://software-dl.ti.com/mcu-plus-sdk/esd/AM64X/11_01_00_17/exports/docs/api_guide_am64x/EVM_SETUP_PAGE.html#EVM_SOC_INIT

For flashing to EMMC you can use UART UNIFLASH with default_sbl_emmc_hs_fs.cfg: https://software-dl.ti.com/mcu-plus-sdk/esd/AM64X/11_01_00_17/exports/docs/api_guide_am64x/TOOLS_FLASH.html#autotoc_md3123

You can try to use this once and check the result. Here SBL EMMC will initialize the SoC and then you can connect to CCS for debugging and you don't need to load the program from CCS then because SBL EMMC will handle it.

As mentioned previously, default_sbl_null is to flash the SBL NULL to OSPI, SBL NULL initializes the core and puts them to WFI but doesn't load any appimage, that is why you load it from CCS, if using SBL NULL you would need to include custom flash configurations as shared previously.

If you face any problems with flashing please share the flashing logs.

Hi Thakar,

Meet Thakar said:

This just indicates the SoC/M4 core is not initialized yet. There are several ways to initialize the SoC, please refer to this guide: https://software-dl.ti.com/mcu-plus-sdk/esd/AM64X/11_01_00_17/exports/docs/api_guide_am64x/EVM_SETUP_PAGE.html#EVM_SOC_INIT

We attempted SoC initialization using DEV BOOT mode and executed the loadJSfile command with the load_dmsc_hsfs.js script. While the scripting logs are visible, the logs in the "AM64X CIO" console, does not proceed or start as outlined in the script.  

     Scripting Console logs, but nothing observed from CIO console.

Currently, we are able to connect via JTAG and successfully debug the image, but this is limited to the R5_0 core only.

Meet Thakar said:

For flashing to EMMC you can use UART UNIFLASH with default_sbl_emmc_hs_fs.cfg: https://software-dl.ti.com/mcu-plus-sdk/esd/AM64X/11_01_00_17/exports/docs/api_guide_am64x/TOOLS_FLASH.html#autotoc_md3123

As per your input, we used UART Uniflash with the default_sbl_emmc_hs_fs.cfg configuration file for flashing to eMMC:

We followed the procedure for UART boot mode and flashed the sbl_emmc_hs_fs.cfg file and also our combined M4 binary. However, only the bootloader begins flashing; the actual image flashing does not initiate. Please find the relevant logs attached.

  Logs of SBL_EMMC image with no communication to EMMC.

Query:

In our custom hardware design, only the primary bootloader selection is implemented. The secondary bootloader section and associated boot selection pins are not utilized(pull down). Could this design choice potentially impact the SoC initialization process, particularly the boot-up of cores such as the Cortex-M4?

Please do revert back with inputs

Thanks and regards

Ganesh Pawar

Hi Ganesh,

ganesh pawar said:

We attempted SoC initialization using DEV BOOT mode and executed the loadJSfile command with the load_dmsc_hsfs.js script. While the scripting logs are visible, the logs in the "AM64X CIO" console, does not proceed or start as outlined in the script.  

This seems strange, are you able to connect to a53 cores at least or is it just R5 for now? Please share the console GEL log as shown here: https://software-dl.ti.com/mcu-plus-sdk/esd/AM64X/11_01_00_17/exports/docs/api_guide_am64x/EVM_SETUP_PAGE.html#autotoc_md41

Another thing to try would be initialization via SBL NULL, I see that you were facing some issues with it previously, but after adding custom flash configuration this should work. Please note that you need to add the custom flash configuration in both SBL NULL and SBL UART UNFLASH and build them again.

ganesh pawar said:

We followed the procedure for UART boot mode and flashed the sbl_emmc_hs_fs.cfg file and also our combined M4 binary. However, only the bootloader begins flashing; the actual image flashing does not initiate. Please find the relevant logs attached.

Did you add custom flash configuration in UART UNIFLASH example and rebuild it before using it? If not you might face this issue.

ganesh pawar said:

In our custom hardware design, only the primary bootloader selection is implemented. The secondary bootloader section and associated boot selection pins are not utilized(pull down). Could this design choice potentially impact the SoC initialization process, particularly the boot-up of cores such as the Cortex-M4?

This should not cause any issues. could you share your bootmode pin configuration for Dev boot mode?

Best regards,

Meet.

Hi Thakar,

Meet Thakar said:

This seems strange, are you able to connect to a53 cores at least or is it just R5 for now? Please share the console GEL log as shown here: https://software-dl.ti.com/mcu-plus-sdk/esd/AM64X/11_01_00_17/exports/docs/api_guide_am64x/EVM_SETUP_PAGE.html#autotoc_md41

The core images are flashed and booted from eMMC, and the A53 core successfully boots using DFU mode, the A53 core comes up as expected.

We are able to detect and connect to the R5 core via JTAG, but only when operating in DEVBOOT mode. In other boot modes, we encounter a "Load program error", and flashing does not proceed.

During SoC initialization, we executed the loadJSfile command using the load_dmsc_hsfs.js script.

The process halts at the sciclient_load_firmware() function, which is called from System_Init().

This indicates that the firmware loading is not completing successfully, preventing full SoC initialization.

logs are attached below is observed during SOC intialization:

Could you revert back what causes this issue and how do i proceed further for Cortex M4.

Thanks and Regards

Ganesh Pawar

Adding to the previous reply, 

Thakar, I’d like to highlight a few points regarding the custom Flash Configuration. According to the guide, the OSPI diagnostics example is supposed to communicate with the custom flash and help determine the necessary configuration settings.

However, in our case, we imported the CCS project, built it, and loaded the image using JTAG in DEVBOOT/NOBOOT mode. The code execution begins at main, but it gets stuck at the CSL_REG32_RD_RAW() function, specifically within Sciclient_waitForMessage().

Additionally, the GEL logs show that only the R5 core is connected, while the M4 core appears to be disconnected. This seems to be causing the issue, as the System Firmware (which typically runs on M4) is likely not active, preventing the Sciclient from receiving a response.

I hope this provides some clarity and helps you guide us further in bringing up the Cortex-M4 core.

Thanks and regards

Ganesh Pawar 

Hi Thakar,

Meet Thakar said:

Please note that you need to add the custom flash configuration in both SBL NULL and SBL UART UNFLASH and build them again

Given the critical nature of this issue, I kindly request that we schedule a call to resolve it efficiently.

Please share your email ID so we can coordinate and proceed further.

Thanks and regards

Ganesh Pawar

Hi Tushar,

Tushar Thakur said:

The issue seems to be with the Sciclient_ccs_init.out binary. A similar issue has already been resolved in below thread.

This indeed was a  sciclient_ccs_init.release.out binary issue, now we are one step ahead with detection of M3 core with JTAG.

Meet Thakar said:

Please note that you need to add the custom flash configuration in both SBL NULL and SBL UART UNFLASH and build them again

Thakar, could you please provide us some insights on the changes to be done and provide further.

Thanks and regards

Ganesh Pawar

Hi Ganesh,

Meet Thakar said:

I assume you are using a different OSPI Flash than the one used on the EVM, Please check this guide on adding support on custom flash device: https://software-dl.ti.com/mcu-plus-sdk/esd/AM64X/11_01_00_17/exports/docs/api_guide_am64x/CUSTOM_FLASH_SUPPORT_GUIDE.html

I did share the steps previously, please try these.

Best Regards,

Meet.

Hi Thakar & Tushar,

Meet Thakar said:

I assume you are using a different OSPI Flash than the one used on the EVM, Please check this guide on adding support on custom flash device: https://software-dl.ti.com/mcu-plus-sdk/esd/AM64X/11_01_00_17/exports/docs/api_guide_am64x/CUSTOM_FLASH_SUPPORT_GUIDE.html

With your guidance, I successfully loaded the OSPI diagnostic example and retrieved the configuration for our custom flash setup, which uses only 4 data lines connected to the processor.

Based on the configuration output from the terminal, we updated the flash settings in the SBL_NULL project. After building and flashing the image, the flasher script appears to load correctly, but the image execution gets stuck.

Upon debugging the project via JTAG, we observed that the execution halts at the Sciclient_waitBootNotification() function. Notably, the Sciclient release image enabled detection of the M4 core. Could there be a linkage or dependency in the Sciclient configuration that needs to be modified to support this setup?

Please provide your inputs on this.

Thanks and regards

Ganesh Pawar

Hi Ganesh,

Are you trying to load the SBL NULL program from CCS after it's already flashed it once? In that case you this is expected.