AM2434: Problems regarding how to use DMASS0

The same program ran well on the LP-AM243. When I used it on my own board, Sciclient_sendMessage() sent a message, but the count of the CUR_CNT of the DMASS0_SEC_PROXY_0_STATUS register of DMASS0 cannot increase. The part of DMAASS0 should have nothing to do with the external design hardware of the MCU. Similarly, the program should not have such a problem. I guess it has something to do with the simulation debugging interface and the emulator identification communication. Could you please check this for me?

Hi Katherine,

Sorry for the delayed response.

Sciclient_sendMessage() is a low-level Sciclient internal function called from multiple Sciclient functions which are called from PowerClock_init(). I gather the call to Sciclient_sendMessage() (for setting DMASS0_SEC_PROXY_0_STATUS:CUR_CNT to 1) is called somewhere in PowerClock_init(). Where is it called?

Are you using the same boot method on the LP and your custom board?

Regards,
Frank

Hi Frank,

It was the same project, and the code was the same.

PowerClock_init()>>>Module_clockEnable()>>>SOC_moduleClockEnable()>>>...>>>Sciclient_sendMessage()

Regards,

Katherine

Hi Katherine,

Thanks for the feedback.

Are you using the same boot method on the LP and your custom board?

Regards,
Frank

Hi Frank,

Yes, the settings were all QSPI. My current problem occurred during the debugging process with CCS.12.10+XDS110 or XDS200.

Regards,

Katherine

Hi Katherine,

Ok, I gather you're using CCS/JTAG for your debugging process.

Are you using SBL NULL (boot from OSPI or SD card) or CCS scripts for SOC initialization?

SOC initialization methods are described here:

• SBL NULL (OSPI): https://software-dl.ti.com/mcu-plus-sdk/esd/AM243X/08_04_00_17/exports/docs/api_guide_am243x/EVM_SETUP_PAGE.html#EVM_FLASH_SOC_INIT
• SBL NULL (SD boot): https://software-dl.ti.com/mcu-plus-sdk/esd/AM243X/08_04_00_17/exports/docs/api_guide_am243x/EVM_SETUP_PAGE.html#EVM_SOC_INIT_SD_BOOT_MODE
• CCS scripts: https://software-dl.ti.com/mcu-plus-sdk/esd/AM243X/08_04_00_17/exports/docs/api_guide_am243x/EVM_SETUP_PAGE.html#EVM_SOC_INIT_NOBOOT_MODE

When you're debugging, are the boot mode pins set the same on your LP and custom hardware platform?

Regards,
Frank

Hi Frank,

Both boards are set to the same boot mode, the main startup is QSPI, and the second startup is NONE. When it is on LP-AM243, it can be debugged normally and correctly. XDS110 or XDS200 cannot work well on the board made by myself.

In addition, is the SBL NULL you mentioned only started in serial mode? Under this mode, the same issue occurred.

Also, after initializing with tools/ccs_load/am243x/load_dmsc.js, and then loading the app, the same thing happened.

Regards,

Katherine

Hi Katherine,

Katherine Wang said:

PowerClock_init()>>>Module_clockEnable()>>>SOC_moduleClockEnable()>>>...>>>Sciclient_sendMessage()

When you observe the unexpected behavior on the custom hardware board, is there any kind of failure returned by the Sciclient() (or other) API functions?

Does the unexpected behavior cause the application to fail during PowerClock_init(), or does the application continue past PowerClock_init() and another failure occurs later on?

Which module clock is being enabled when the behavior occurs? You should be able to determine this finding the value of the index (variable i) into the gSocModules[] array, and then inspecting the gSocModules[] array in ti_power_clock_config.c.c.

Katherine Wang said:

Both boards are set to the same boot mode, the main startup is QSPI, and the second startup is NONE.

I don't understand. Only one boot mode can be selected at a time.

Both boards are normally set to QSPI boot (i.e. SBL and application are in QSPI flash)?

When are you using the NONE second startup method? When debugging over JTAG?

Katherine Wang said:

XDS110 or XDS200 cannot work well on the board made by myself.

They don't work well (maybe due to some JTAG hardware signaling issue), or they don't work at all?

Katherine Wang said:

is the SBL NULL you mentioned only started in serial mode?

Can you please elaborate? What is "serial mode"?

Additional details on bootflow and bootloaders can be found here: https://software-dl.ti.com/mcu-plus-sdk/esd/AM243X/08_04_00_17/exports/docs/api_guide_am243x/BOOTFLOW_GUIDE.html

SBL NULL details can be found here: https://software-dl.ti.com/mcu-plus-sdk/esd/AM243X/08_04_00_17/exports/docs/api_guide_am243x/BOOTFLOW_GUIDE.html#autotoc_md263

Katherine Wang said:

after initializing with tools/ccs_load/am243x/load_dmsc.js, and then loading the app, the same thing happened.

On the custom hardware board set for NO BOOT and using CCS scripting, you observe the issue after loading and executing the program?

This confuses me since the CCS scripting method requires a JTAG connection. How is CCS scripting working on your custom hardware board if JTAG (XDS110/XDS200) can't work on your custom board?

Please see details on NO BOOT pin settings here: NO BOOT: https://software-dl.ti.com/mcu-plus-sdk/esd/AM243X/08_04_00_17/exports/docs/api_guide_am243x/EVM_SETUP_PAGE.html#BOOTMODE_NOBOOT

Regards,
Frank

Frank Livingston said:

Can you please elaborate? What is "serial mode"?

Hi Frank,

Sorry, it should be 'uart boot mode'. 

And the customer thought that it might have something to do with the ARM kernel debugging system.

Regards,

Katherine

Hi Katherine,

Katherine Wang said:

Sorry, it should be 'uart boot mode'. 

Ok, thanks for the clarification.

SBL NULL is described here: https://software-dl.ti.com/mcu-plus-sdk/esd/AM243X/08_04_00_17/exports/docs/api_guide_am243x/BOOTFLOW_GUIDE.html#autotoc_md263

SBL NULL is typically flashed to OSPI or SD and then booted from one of those non-volatile memory sources.

Regards,
Frank

Hello,

Katherine Wang said:

the second startup is NONE.

Sorry for the confusion here. I've confirmed with the customer that he meant he didn't set a Backup Boot.

XDS110 or XDS200 could be connected to debug MCU, but the board itself was stuck at the PowerClock_init() function and couldn't go past it.

SOC_moduleClockEnable() would fail to enable any module, including UART, etc., and enter Sciclient_waitForMessage(), an infinite loop.

The customer programmed the SBL again yesterday, and somehow everything seemed to work well. Could you please tell him why? Is it because the SBL is damaged, and the DMSC cannot detect the correct SBL and thus shut down all modules directly?

Regards,

Katherine

Hi Katherine,

Thanks for the feedback.

My current understanding is:

• The boot method for both LP and customer HW board is SBL OSPI. The custom HW board fails to properly execute the application, but it's unknown exactly why the failure occurs.
• To debug the issue, the boards were placed in NO BOOT mode & CCS scripting is used for SOC initialization.
  • LP: no hang observed.
  • Custom board: application hang in PowerClock_init().
• After reflashing the SBL OSPI on the custom HW board, the boot failuire is no longer observed.

Did the customer try debugging the failure on the custom HW board while SBL OSPI was still being used?

To do this:

• Add spinlock at start of application before System_init(). See <SDK>\examples\drivers\boot\sbl_ospi\am243x-lp\r5fss0-0_nortos\main.c for an example.
• Rebuild/reflash application.
• After boot, launch target in CCS.
• Connect to R5F0_0 without using "on target connect" GEL function.
• Load symbols from .out file.
• Disable spinlock to allow application to proceed.
• Step through PowerClock_init() to see if hang occurs.

Katherine Wang said:

The customer programmed the SBL again yesterday, and somehow everything seemed to work well. Could you please tell him why? Is it because the SBL is damaged, and the DMSC cannot detect the correct SBL and thus shut down all modules directly?

No, I can't say for certain.

Did the customer use Uniflash (UART or JTAG)? https://software-dl.ti.com/mcu-plus-sdk/esd/AM243X/08_04_00_17/exports/docs/api_guide_am243x/TOOLS_FLASH.html

When originally flashing the SBL/app on the custom HW board, did the customer observe any error during the flashing process?

If the customer repeatedly reflashes, can the same boot error be reproduced?

Regards,
Frank

Hi Frank，

I added a spin lock, but the result is still the same. I‘m not very clear about the purpose of adding a spin lock. Could you please elaborate on it? 

status = Spinlock_lock(CSL_SPINLOCK0_BASE,3);

...

Spinlock_unlock(CSL_SPINLOCK0_BASE,3);

Regards,

Katherine

Hi Katherine,

The idea was to add a software spinlock, not a hardware spinlock. Please see see <SDK>\examples\drivers\boot\sbl_ospi\am243x-evm\r5fss0-0_nortos\main.c for an example:

/* call this API to stop the booting process and spin, do that you can connect
 * debugger, load symbols and then make the 'loop' variable as 0 to continue execution
 * with debugger connected.
 */
void loop_forever()
{
    volatile uint32_t loop = 1;
    while(loop)
        ;
}

This type of spin can be added to the application. After the application boot, you can connect to the core using JTAG, load symbols, set loop=0, and step through PowerClock_init().

The idea is to confirm you see the same failure when bootloading vs when using NO BOOT mode and loading the appliation from JTAG.

Repeating my question: if the customer repeatedly reflashes, can the same boot error be reproduced?

Regards,
Frank

Hi Frank,

A software spinlock, does it mean that it loops and waits for the DMSC to prepare the device backstage? Or what is the purpose for this? The phenomenon observed on my side is that as long as the SBL is solidified in the flash, the program can execute PowerClock_init() normally, otherwise it will wait for an infinite loop inside PowerClock_init().

I've checked the SDK source code. The SCI interface function in it should be that DMSC completely controls the MCU peripherals. The APP must communicate with DMSC to enable peripheral modules. At the same time, when the DMSC is in the QSPI boot mode, it is necessary to check whether there is a complete SBL in the Flash. If not, the related peripherals will be disabled. I wonder if my understanding is correct?

In addition, DMSC is equivalent to the BIOS in a PC, which manages peripherals, but it is difficult to use. Could the DMSC function be disabled and could the user's own SBL or APP completely control the enabling and banning of peripherals when the Flash is all empty (0xFF)?

Regards,

Katherine

Hi Frank,

The customer inquired whether there were any updates on his issue. Could you please follow up on this?

Thanks and regards,

Katherine

Hi Katherine,

Sorry for the delayed response. I'll review and get back with you shortly.

Regards,
Frank

Hi Katherine,

Thanks for your patience on this issue.

Katherine Wang said:

A software spinlock, does it mean that it loops and waits for the DMSC to prepare the device backstage? Or what is the purpose for this?

The purpose is to prove the application code fails in PowerClock_init() after the SBL has completed. I was under the impression the application failure also occurred on the customer hardware when using CCS scripting for SOC initialization.

I'll summarize my current understanding of the situation. Can you please confirm whether my summary is correct?

Uniflash is used for writing OPSI SBL, SYSFW, and the application to the flash.

The boot method for both LP and customer HW board is SBL OSPI.

• The LP boots and executes correctly.
• The custom HW board fails to properly execute the application after boot. After connecting JTAG and loading symbols, it was determined the application code is stuck looping in PowerClock_init().

If the boards were placed are placed in NO BOOT mode & CCS scripting is used for SOC initialization:

• LP: no hang observed.
• Custom board: no hang is observed.

This means the issue only occurs with OSPI boot on the custom HW.

After reflashing the SBL OSPI on the custom HW board, the boot failure is no longer observed.

Katherine Wang said:

The phenomenon observed on my side is that as long as the SBL is solidified in the flash, the program can execute PowerClock_init() normally, otherwise it will wait for an infinite loop inside PowerClock_init().

Ok, so this issue is with Uniflash, not with the the SBL, SYSFW, PowerClock_init(), or the DMASS. Is this correct? Does Uniflash report any errors during flashing for the failing case?

Regards,
Frank