AM2634: Cores unhalt issue when there is no wait after updating the register.

Abdelrhman Afifi

Part Number: AM2634

Hello,

From the SDK I see Bootloader_runCpu API is doing the unhalt process, is there any register to check the status of the CPU to make sure it has started?

I see removing extra unneeded code like Bootloader_socCpuRelease and Bootloader_socGetCoreName makes some issues and the core does not start properly without adding a delay after unhalt process.

Could you please guide me on this?

I can see these extra APIs calls are working the same as a delay so how to check the have started correctly(register or flag)?

Yours,
Abdelrhman Afifi

over 1 year ago

0 Aakash Kedia over 1 year ago

TI__Mastermind 26145 points

Hi Abdelrhman Afifi,

You can read through these registers in the memory -

Unfortunately we don't have an API in SDK which reads through the same. I can take the feedback and request addition of the same.

Best Regards,
Aakash

0 Abdelrhman Afifi over 1 year ago in reply to Aakash Kedia

Intellectual 415 points

Hello Aakash Kedia,

This register states the WFI and WFE, what should be read?

I tried to poll over MSS_CTRL_R5SS1_CORE0_HALT and MSS_CTRL_R5SS1_CORE1_HALT after writing the register, but the values are changed immediately after updating the register so I added some delay.

The delay is just consuming some clock cycles which are already consumed in Bootloader_socCpuRelease, Bootloader_socCpuGetClock, and Bootloader_socGetCoreName.

Bootloader_socCpuRelease API is just returning true, Bootloader_socCpuGetClock and Bootloader_socGetCoreName are updating a global variable without affecting the unhalt process.

Could you guide me on why this delay is needed?

Best Regards,
Abdelrhman Afifi

0 Aakash Kedia over 1 year ago in reply to Abdelrhman Afifi

TI__Mastermind 26145 points

Hi Abdelrhman Afifi,

Abdelrhman Afifi said:
This register states the WFI and WFE, what should be read?

If your CPU is in WFI, it will set the WFI bit but if your CPU is in execution, it will set WFE.

The wait states are only valid if you are using FSM trigger reset.

This FAQ explains different types of reset - https://e2e.ti.com/support/microcontrollers/arm-based-microcontrollers-group/arm-based-microcontrollers/f/arm-based-microcontrollers-forum/1342613/faq-mcu-plus-sdk-am263x-what-are-the-difference-types-of-reset-in-the-soc

I hope this helps.

Best Regards,
Aakash

0 Abdelrhman Afifi over 1 year ago in reply to Aakash Kedia

Intellectual 415 points

Hello,

I don't have issues with core 0 it is always started after the FSM reset. The issue is with Core 2 and Core 3.

But If Core 2 and Core 3 are unhalt and immediately trigger FSM reset for Core 0 there will be an issue with Core 2 and Core 3. If a delay is added after the unhalt there is no issue.

Why is a delay needed?

Yours,
Abdelrhman Afifi

0 Aakash Kedia over 1 year ago in reply to Abdelrhman Afifi

TI__Mastermind 26145 points

Hi Abdelrhman Afifi,

What is the issue with Core 2 and Core 3 when Core 0 asserts the FSM trigger ? Can you share the reproduced issue with us ?

Best Regards,
Aakash

0 Abdelrhman Afifi over 1 year ago in reply to Aakash Kedia

Intellectual 415 points

Hello,

Core 2 and Core 3 don't start correctly, but after adding a delay before triggering the FSM reset from Core 0 they work fine.

Yours,
Abdelrhman Afifi

0 Abdelrhman Afifi over 1 year ago in reply to Abdelrhman Afifi

Intellectual 415 points

Hi,

How long does it take to reset the main core?

BR,
Abdelrhman Afifi

0 Aakash Kedia over 1 year ago in reply to Abdelrhman Afifi

TI__Mastermind 26145 points

Hi Abdelrhman Afifi,

Core 2 and Core 3 also go through a FSM trigger for R5SS1. It requires a delay as well as this is a subsystem reset. It is configured as 7 in MCU_PLUS_SDK.

Best Regards,
Aakash

Arm-based microcontrollers

Arm-based microcontrollers forum

AM2634: Cores unhalt issue when there is no wait after updating the register.