MCU-PLUS-SDK-AM263PX: AM263Px

Rapeti Sravanthi

Tool/software:

1. Debugger requires Power-On Reset (POR) to run project

On first-time debugging of an example project on the AM263Px LaunchPad, the application runs successfully.
However, on subsequent debug attempts (after terminating the debug session), the project does not run unless I perform a Power-On Reset (POR).
If I try to debug without a POR, the CPU halts and enters an infinite while loop, as shown in the attached image.

Is it expected that a POR is required before each debug session?
Or is there a recommended way to recover or reinitialize the SoC state (e.g., via CCS reset, GEL script, or software reset) without performing a POR?

2. R5FSS core configuration and status register behavior

I am importing the HelloWorld example from MCU+ SDK and attempting to change the core configuration by writing to the R5FSS control register:

HW_WR_REG32(0x50D00020, 0x07000000); // Attempting to set dual-core mode

Then, I read the R5FSS_0 Status Register (0x50D00010), but I always get the value: 0x00000001

This same value is read even without modifying any core configuration.
According to the TRM, the default boot configuration should place the R5F cores in lockstep mode, in which case the 8th bit (bit 7) of the status register should be 1. However, this bit remains 0 in my case.

Am I missing some initialization step or sequencing requirement before reading the R5FSS status register? Should the default boot mode not reflect lockstep mode in the status register?

4 months ago

0 Nilabh Anand 4 months ago

TI__Mastermind 45154 points

Hi Rapeti,

Apologies you had to face the above issue.

Rapeti Sravanthi said:
1. Debugger requires Power-On Reset (POR) to run project

On first-time debugging of an example project on the AM263Px LaunchPad, the application runs successfully.
However, on subsequent debug attempts (after terminating the debug session), the project does not run unless I perform a Power-On Reset (POR).
If I try to debug without a POR, the CPU halts and enters an infinite while loop, as shown in the attached image.

Is it expected that a POR is required before each debug session?
Or is there a recommended way to recover or reinitialize the SoC state (e.g., via CCS reset, GEL script, or software reset) without performing a POR?

This is a bug in the AM263Px gel script. This will get fixed in next CCS theia release for existing releases, please follow this work around:

https://e2e.ti.com/support/microcontrollers/arm-based-microcontrollers-group/arm-based-microcontrollers/f/arm-based-microcontrollers-forum/1507590/faq-mcu-plus-sdk-am263px-am263px-in-dev-boot-mode-terminating-and-relaunching-the-debug-session-does-not-take-care-of-soc-reset

0 Nilabh Anand 4 months ago

TI__Mastermind 45154 points

Rapeti Sravanthi said:
2. R5FSS core configuration and status register behavior

I am importing the HelloWorld example from MCU+ SDK and attempting to change the core configuration by writing to the R5FSS control register:

HW_WR_REG32(0x50D00020, 0x07000000); // Attempting to set dual-core mode

Then, I read the R5FSS_0 Status Register (0x50D00010), but I always get the value: 0x00000001

This same value is read even without modifying any core configuration.
According to the TRM, the default boot configuration should place the R5F cores in lockstep mode, in which case the 8th bit (bit 7) of the status register should be 1. However, this bit remains 0 in my case.

Am I missing some initialization step or sequencing requirement before reading the R5FSS status register? Should the default boot mode not reflect lockstep mode in the status register?

For configuring the lockstep and dual core mode in CCS debug(dev boot mode), Please us the scripts icon in CCS and use the hot menu, let me know if you face any difficulty:

0 Nilabh Anand 4 months ago in reply to Nilabh Anand

TI__Mastermind 45154 points

Also for questions on AM263Px, please select org as ASM-IND

0 Rapeti Sravanthi 4 months ago in reply to Nilabh Anand

Prodigy 145 points

Thanks for the reply,

Rapeti Sravanthi said:
2. R5FSS core configuration and status register behavior

I would like to understand why I am not getting the expected result after following the procedure mentioned above.

Nilabh Anand said:
For configuring the lockstep and dual core mode in CCS debug(dev boot mode), Please us the scripts icon in CCS and use the hot menu, let me know if you face any difficulty:

when I perform this step, I encounter an error (please see the attached image).Could you please help me understand what might be causing this issue?

0 Nilabh Anand 4 months ago in reply to Rapeti Sravanthi

TI__Mastermind 45154 points

Hi Rapeti,

Seems like a issues related to debugger and CCS,

could you please reset the board and restart CCS and try again. Also which boot mode are you using (I am referring to boot pins on the device?)

0 Rapeti Sravanthi 4 months ago in reply to Nilabh Anand

Prodigy 145 points

Hii,

Thanks for the reply,

I am using in device boot mode. And it worked .

I'm configuring the core frequency to 400 MHz and the system frequency to 200 MHz via CCS scripting. However, when I query the clock frequency using the SOC_getSelfCpuClk() API:

For Core = 400 MHz, SYSCLK = 200 MHz, I got 160 MHz from SOC_getSelfCpuClk()
For Core = 200 MHz, SYSCLK = 200 MHz, I got 80 MHz

This seems inconsistent with the expected configured frequencies. Could you please explain why this discrepancy occurs?

I am continuously toggling a GPIO (screenshot attached), and I observed:

High duration: ~60 ns
Low duration: ~58 ns

That results in a total period of ~118 ns (roughly 8.47 MHz toggle rate).

Given that the core frequency is configured to 400 MHz, is this toggle rate expected?

0 Nilabh Anand 4 months ago in reply to Rapeti Sravanthi

TI__Mastermind 45154 points

Hi Rapeti,

Rapeti Sravanthi said:
Thanks for the reply,

I am using in device boot mode. And it worked .

Glad to know that it worked.

For the CPU frequency observation, allow me to comeback on it by Tuesday next week, feel free to ping here in case I have not gotten back.

0 Rapeti Sravanthi 4 months ago in reply to Nilabh Anand

Prodigy 145 points

Hii Anand,

Thank you for the update. Sure, I’ll wait for your response regarding the CPU frequency and the observed GPIO toggling rate.

0 Nilabh Anand 4 months ago in reply to Rapeti Sravanthi

TI__Mastermind 45154 points

Hi Rapeti,

Rapeti Sravanthi said:
I am continuously toggling a GPIO (screenshot attached), and I observed:

High duration: ~60 ns

Low duration: ~58 ns

That results in a total period of ~118 ns (roughly 8.47 MHz toggle rate).

Given that the core frequency is configured to 400 MHz, is this toggle rate expected?

GPIO toggling also has over head of the GPIO register write time overhead

0 Rapeti Sravanthi 4 months ago in reply to Nilabh Anand

Prodigy 145 points

Thanks for the reply,

Is there any way to check ,How many cycles or time does an instruction takes to execute. If present please tell the procedure to perform it.

Rapeti Sravanthi said:
I'm configuring the core frequency to 400 MHz and the system frequency to 200 MHz via CCS scripting. However, when I query the clock frequency using the SOC_getSelfCpuClk() API:

For Core = 400 MHz, SYSCLK = 200 MHz, I got 160 MHz from SOC_getSelfCpuClk()

For Core = 200 MHz, SYSCLK = 200 MHz, I got 80 MHz

Is there any update regarding this query??

0 Nilabh Anand 4 months ago in reply to Rapeti Sravanthi

TI__Mastermind 45154 points

Hi Rapeti,

Please refer to this code on steps to measure the cycle:

mcupsdk-core/examples/benchmarks/sram_overlay_benchmark/sram_overlay.c at next · TexasInstruments/mcupsdk-core · GitHub

Arm-based microcontrollers

Arm-based microcontrollers forum

MCU-PLUS-SDK-AM263PX: AM263Px

1. Debugger requires Power-On Reset (POR) to run project

2. R5FSS core configuration and status register behavior

1. Debugger requires Power-On Reset (POR) to run project

2. R5FSS core configuration and status register behavior