TMDS64EVM: Reset and reboot the AM64

Hi Kiyomasa,

Thanks for your query.

Kiyomasa Imaizumi said:

Please tell me how to reset and reboot while each CPU firmware is running. After rebooting, I would like to start from the CR5 SBL.

Can you please tell us what is the use case here?

Can you please confirm, do you mean resetting the SoC through firmware running on one core(say R5F) while other cores are also running?

Regards,

Tushar

Hello Tushar Thakur.

Thank you for your reply.

The use case is as follows:
When the primary power supply is switched on, the SBL runs, followed by the CR5 (including PRU) and CA53 application firmware.
For example, the user will press a button (GPIO), the CA53 will interpret the button press, and the CA53 application firmware will reset each CPU, and then the system will reboot from the SBL.

I mean resetting the all SoC through firmware running on one core(CA53) while other cores are also running.

Please tell me the procedure for resetting and rebooting each CPU (CR5, PRU, CA53) using the CA53 application.

Best regards,

Kiyomasa Imaizumi.

Hello Swargam Anil,

Thank you for your reply.

No.1
Can POR be performed not only by a hardware switch, but also by writing "0110" to the SW_MAIN_POR [4:7] field of the CTRLMMR_MCU_RST_CTRL register?

No.2
In terms of the reset mechanism, does writing CTRLMMR_MCU_RST_CTRL generate an M4F core interrupt and reset the MAIN domain?

No.3
Also, is it OK to write "0110" to SW_MAIN_POR or SW_MAIN_WARMRST of CTRLMMR_MCU_RST_CTRL in the CA53 interrupt handler to perform a software reset?

Best regards.
Kiyomasa Imaizumi.

Hello Kiyomasa Imaizumi,

Please look at the FAQ below for more details on the Reset topic.

This FAQ clears all your doubts.

https://e2e.ti.com/support/processors-group/processors/f/processors-forum/1407057/faq-reset-topic-on-am64x-am243-am62x-soc-s

Regards,

Anil.

Hello Swargam Anil.
Thank you for your reply.

I checked 0636.reset_Analysis.xlsx.

---
How can I determine whether the current firmware is in Generic Mode or Isolation Mode?
In other words, how can I determine whether my firmware separates the M4F core from the MAIN Domain or not?

---
In the Peripheral Status of the MAIN Dominin Software POR, it says

>In Generic Mode: No Reset effect

What does this mean? Does it mean that the register values ​​of all peripherals are retained?

---
The following is written in the Software POR Comments:

>1. Software POR operation will not work in generic mode, which means that when user configures M4F core in non-isolated mode, user can't do Sofwatre POR. User can do Sofwtare POR when M4F core in isolation mode only

Currently, writing "0110" to SW_MAIN_POR [4:7] in CTRLMMR_MCU_RST_CTRL resets the M4F core, but is this because the M4F is isolated and in isolation mode?

Best regards,
Kiyomasa Imaizumi.

Hello Kiyomasa Imaizumi,

All MCU+SDK examples do not have feature of Isolating  MCU  core.

If you want to Isolate M4F core from MAIN  domain, then please refer examples below and chapter.

The POR does not work even if you control  the CTRL MMR register for POR bits in Generic mode (Not isolating MCU core from MAIN domain ).

The POR will work when you Isolate the MCU core from the MAIN domain.

https://software-dl.ti.com/mcu-plus-sdk/esd/AM64X/10_00_00_20/exports/docs/api_guide_am64x/MCU_RESET_ISOLATION.html

Examples code path :   \ti\mcu_plus_sdk_am64x_10_00_00_20\examples\drivers\safety\reset_isolation.

Regards,

Anil.

Hello Swargam Anil.

Thank you for your reply.

>1. Software POR operation will not work in generic mode, which means that when user configures M4F core in non-isolated mode, user can't do Sofwatre POR. User can do Sofwtare POR when M4F core in isolation mode only
>All MCU+SDK examples do not have feature of Isolating MCU core.

I have noticed something strange about POR.
In the following sample project, I created code to write "0110" to the SW_MAIN_POR register of CTRLMMR_RST_CTRL.

gpio_input_interrupt_am64x-evm_r5fss0-0_nortos_ti-arm-clang.zip

When loaded and run on XDS110, a POR reset does not occur.
I think this is correct.
However, when booting from the ROM with OSPI Flash, a POR reset occurs.
According to the explanation so far, M4F is not separated in the sample project, so POR should not work.

Why does POR work when booting from ROM?

Best regards,

Kiyomasa Imaizumi.1212.gpio_input_interrupt_am64x-evm_r5fss0-0_nortos_ti-arm-clang.zip

Hello Swargam Anil.

Please respond regarding the behavior of the above POR.

Best regards,
Kiyomasa Imaizumi.

Hello Kiyomasa Imaizumi,

Please look at the image below.

As per TRM, when the M4F core is configured as a general purpose core, then the user can't use the SW POR to make the POR and the user should use the MCU_PORz pin to make the SOC Reset and this is recommended.

This SW POR works in the current scenario as above and I have seen in other Hw's, after triggering the SW POR the boot is not started and hags in the ROM bootloader. So, please don't use SW POR in generic mode.

Regards,

Anil.

Hello Swargam Anil.

In the diagram above, there are three M4F states.
case 1: M4FSS as "Independent" Safety Processor
case 2: M4FSS as "Monitoring" Safety Processor
case 3: M4FSS as General-Purpose Processor or Not Used.

When writing firmware for CA53 or CR5 that I created myself, how can I check which M4F case it is?

Best regards,
Kiyomasa Imaizumi.

Additional note.
The CR5 and CA53 applications are running, but I don't know what state the M4F is in at that time. In other words, whether it's Generate-Purpose, Safety, or Not Used.
Even if it's a Safety Processor, I don't know whether it's Independent or Monitoring, or what safety function it's performing.

Best regards,

Kiyomasa Imaizumi.

Hello Kiyomasa Imaizumi,

I am looking at your queries and you may expect reply by today .

Regards,

Ani

Hello Swargam Anil.

Thank you. I am waiting for your reply.
Regarding the first question about the above sample project, could you please explain why a POR reset does not occur when booting from RAM, but does occur when booting from ROM with OSPI Flash?

Best reagrds,
Kiyomasa Imaizumi.

Hello Kiyomasa Imaizumi,

Kiyomasa Imaizumi said:

In the diagram above, there are three M4F states.
case 1: M4FSS as "Independent" Safety Processor
case 2: M4FSS as "Monitoring" Safety Processor
case 3: M4FSS as General-Purpose Processor or Not Used.

When writing firmware for CA53 or CR5 that I created myself, how can I check which M4F case it is?

All MCU+SDK examples do not have features of Isolating MCU core.

If you want to Isolate M4F core from the MAIN  domain, then please refer to examples below and chapter.

Examples code path :   \ti\mcu_plus_sdk_am64x_10_00_00_20\examples\drivers\safety\reset_isolation.

https://software-dl.ti.com/mcu-plus-sdk/esd/AM64X/10_00_00_20/exports/docs/api_guide_am64x/MCU_RESET_ISOLATION.html

If you look at the Reset Isolation example, there are flags to disable the MAIn2MCU and MCU2MAIn PSC bridges.

If these bridges are enabled and the Reset Isolation flag is set, then M4F can be configured as M4F monitoring mode.

If these bridges are disabled and the Reset Isolation flag is set, then the M4F can be configured as M4F as a safety processor.

If these bridges are enabled and the Reset Isolation flag is not set, then M4F can be configured as M4F Generic mode.

Please look at the flow charts and examples and MCU+SDK documentation for enabling Reset Isolation steps .

Kiyomasa Imaizumi said:

Thank you. I am waiting for your reply.
Regarding the first question about the above sample project, could you please explain why a POR reset does not occur when booting from RAM, but does occur when booting from ROM with OSPI Flash?

Please look at the answer below for the above query.

Swargam Anil said:

Please look at the image below.

As per TRM, when the M4F core is configured as a general purpose core, then the user can't use the SW POR to make the POR and the user should use the MCU_PORz pin to make the SOC Reset and this is recommended.

This SW POR works in the current scenario as above and I have seen in other Hw's, after triggering the SW POR the boot is not started and hags in the ROM bootloader. So, please don't use SW POR in generic mode.

Regards,

Anil.

Hello Swargam Anil.

Thank you for your reply.

I built the sample project below and got reset_isolation_system.appimage.hs_fs.
C:\ti\mcu_plus_sdk_am64x_09_01_00_41\examples\drivers\safety\reset_isolation

After writing to the TMDS64EVM’s OSPI flash and powering it on, the following debug output was displayed:

---
DMSC Firmware Version 9.1.6--v09.01.06 (Kool Koala)
DMSC Firmware revision 0x9
DMSC ABI revision 3.1

Some tests have failed!!
---

The application may start if you turn the power on and off several times.

I use the following as my SBL OSPI:
sbl_prebuilt/am64x-evm/sbl_dfu_uniflash.release.hs_fs.tiimage
Am I missing some setting in SBL OSPI?

Please tell me how to solve this problem.

Best reagrds,
Kiyomasa Imaizumi.

Hello Kiyomasa Imaizumi,

Can you please try the SBL_OSPI rather than dfu uniflash image and share the Test results ?

Regards,

Anil.

Hello Swargam Anil.

Thank you for your reply.

I am using sbl_ospi.debug.hs_fs.tiimage.
I am attaching an application image.

When I write to the OSPI flash and apply power I get the error "Some tests have failed!!"
However, when I pressed SW7 on the EVM, it started up as shown below.

--CR5 monitor---
DMSC Firmware Version 9.1.6--v09.01.06 (Kool Koala)
DMSC Firmware revision 0x9
DMSC ABI revision 3.1

[BOOTLOADER_PROFILE] Boot Media : NOR SPI FLASH
[BOOTLOADER_PROFILE] Boot Media Clock : 166.667 MHz
[BOOTLOADER_PROFILE] Boot Image Size : 38 KB
[BOOTLOADER_PROFILE] Cores present :
m4f0-0
r5f0-0
[BOOTLOADER PROFILE] SYSFW init : 12170us
[BOOTLOADER PROFILE] System_init : 349499us
[BOOTLOADER PROFILE] Drivers_open : 321us
[BOOTLOADER PROFILE] Board_driversOpen : 23228us
[BOOTLOADER PROFILE] Sciclient Get Version : 10033us
[BOOTLOADER PROFILE] CPU Load : 49515us
[BOOTLOADER_PROFILE] SBL Total Time Taken : 444772us

Image loading done, switching to application ...
Run CPU m4f0-0 to 400000000 Hz.
Run CPU r5f0-0 to 800000000 Hz.
Starting R5
Press and release SW5 button on EVM to trigger warm reset from SW...
Press and release SW4 button on EVM to trigger a warm reset from HW..

I am running (R5) !!:- 0
I am running (R5) !!:- 1
-----

--M4F monitor---
I am running (M4) !!:- 0
I am running (M4) !!:- 1
I am running (M4) !!:- 2
I am running (M4) !!:- 3
I am running (M4) !!:- 4
-----

There is one more problem.
When I try to connect target from CCS to M4F in this state, an error occurs.

Please tell me how to solve this.

resetisolation.zip

Best regards,
Kiyomasa Imaizumi.

Additional note:
When I changed debugIsolationEnable in reset_isolation_mcu_domain.c from 1 to 0, I was able to connect to the M4F from CCS.

If debugIsolationEnable=1, does this mean that I cannot connect from XDS110?

Best regards,

Kiyomasa Imaizumi.

Additional note:
The following code is found in reset_isolation_main in reset_isolation_mcu_domain.c.
-------
{
HwiP_Params resetHwiParams;
HwiP_Object resetObject;

HwiP_Params_init(&resetHwiParams);
resetHwiParams.intNum = 25;
resetHwiParams.callback = resetReqIsr;
resetHwiParams.isPulse = 0;
HwiP_construct(&resetObject, &resetHwiParams);
}
-------

Since intNum=25 is MCU_UART1_USART_IRQ_0, I think this is the UART1 interrupt.
Why does pressing SW4 on TMDS64EVM cause resetReqIsr to occur on the M4F?

Best regards,
Kiyomasa Imaizumi.

Hello Kiyomasa Imaizumi,

Kiyomasa Imaizumi said:

When I changed debugIsolationEnable in reset_isolation_mcu_domain.c from 1 to 0, I was able to connect to the M4F from CCS.

If debugIsolationEnable=1, does this mean that I cannot connect from XDS110?

To connect the debugger to M4F core, the above step is OK and your understanding is correct.

Kiyomasa Imaizumi said:

The following code is found in reset_isolation_main in reset_isolation_mcu_domain.c.
-------
{
HwiP_Params resetHwiParams;
HwiP_Object resetObject;

HwiP_Params_init(&resetHwiParams);
resetHwiParams.intNum = 25;
resetHwiParams.callback = resetReqIsr;
resetHwiParams.isPulse = 0;
HwiP_construct(&resetObject, &resetHwiParams);
}
-------

Since intNum=25 is MCU_UART1_USART_IRQ_0, I think this is the UART1 interrupt.
Why does pressing SW4 on TMDS64EVM cause resetReqIsr to occur on the M4F?

The above query make sense. Actually you need to check the 9th interrupt number rather than 25. Since the M4F core interrupts starts from 16. These interrupts are internal and specific to SOC. So, users can't use them.

To route an interrupt to M4F core you need to add the offset value is 16 + M4F core interrupt number.

Now, we are routing warmReset interrupt to M4F core.

In this case, the warmReset interrupt number is 9 and the offset value is 16, so The Total value is 25.

Regards,

Anil.

Hello Swargam Anil.

Thank you for your reply.

For reference, is there any specification anywhere that states that the M4F core's interrupts start at 16?

Best regards,
Kiyomasa Imaizumi.