AM625-Q1: ClockP_getTimeUsec return abnormal value with CCS debugging

Hello Tony,

The thread seems to be assigned to a different RO and, again, it is assigned my name.

I am looking at your queries, and you may expect a reply by the end of the day.

Regards,

Anil.

Hello,This issue is that I asked Tony to submit. It is about a bare‑metal program running on the A53ss1-0 core. I found that when debugging the program in debug mode, calling the ClockP_getTimeUsec() function returns abnormal microsecond values, and the delay time of the ClockP_sleep function is also abnormal. I suspect this is caused by an overflow of the clock tick count.

Hello Tony,

Can you please confirm you are running FreeRTOS/NORTOS on A531_0 core ?

When you load an example from CCS, is that time are other A53 cores running or not loading from CCS ?

Yes, if the counter is overflowing, then there may be a chance we might get a big number.

Instead of using the 32bit counter, use the GTC timer and still see if you face the same issue or not.

Because the GTC timer is a 64bit timer and the GTC timer overflows after ~1490 years.

Regards,

Anil.

running NORTOS on A531_0 core and other A53 cores running SDK hello_world example

Hello ,

Sorry for delayed response. I have tied up with internal team meetings over the last couple of days.

I reviewed all the A53 examples, and each A53 core is using its own timer instance.

There is no timer sharing between cores, so there is no misuse or interference from another core.

The abnormal timing looks like a counter overflow issue, and not any functional problem in the software. Since the  timer runs at 25 MHz, it will overflow roughly every ~2 minutes. 

To avoid this overflow, it’s better to use the GTC (Global Time Counter) instead. You can enable the GTC timer directly from SysConfig. After enabling it, read the 64-bit counter value from the GTC registers. The GTC counter effectively never overflows for your use-case, so timing measurements remain stable and accurate.

Regards,

Anil.

Hello,
When I flash this code into the on-board FLASH via the serial port and run it normally (instead of in debug mode), it works fine and there is no overflow.
Have you ever tried using the SK-AM62 EVM and its on-board XDS110 to debug a “hello world” program?
On this board, when I run the “hello world” program in debug mode and additionally read the value returned by ClockP_getTimeUsec(), I also observe abnormal behavior.

Hello ,

I did not test at my side and, based on the above information I still feel this issue might be with the 32 bit Timer overflow.

I can confirm at my side. Meanwhile, if you are stuck or facing problem with any measurement due to this 32bit timer, instead of this timer, use the 64bit GTC timer.

I can check at my side and let you know status on Monday.

Regards,

Anil.

Hello,

I am not able to reproduce the issue at my side and the example code is running properly at my side.

Attached the code for your reference.

I feel that, based on the above results, the same UART is used in the different A53 cores.

You do one thing: keep the UART running in the A53_1_0 core and keep the UART disabled in all other A53 cores.

And, please confirm the Test Results.

/cfs-file/__key/communityserver-discussions-components-files/791/hello_5F00_world_5F00_am62x_2D00_sk_5F00_a53ss1_2D00_0_5F00_nortos_5F00_gcc_2D00_aarch64.zip

Regards,

Anil.

Hello

As shown in the video, you can see that I have imported the project you provided, and I'm running the program by flashing it into the DDR via debug mode.
When entering debug mode for the first time, the program works normally: printing operates correctly, it returns the right values, and breakpoints are hit as expected.
However, when I reset the device and reload the firmware in debug mode, the program behaves abnormally: printing fails to work properly, breakpoints cannot be entered, and as the video shows, it gets stuck.

I suspect that in debug mode, after resetting the device in the IDE, the SOC's clock becomes abnormal. This causes the DebugP_log API to wait for a semaphore, and due to the abnormal clock ticks, it results in an infinite delay. Additionally, this issue leads ClockP_getTimeUsec to retrieve abnormal tick counts, making the returned values appear as if they are overflowing.

Hello zegeng Huang,

When we perform a CPU reset, only the CPU registers are cleared.
All other system components continue to hold their previous state and memory content.

In this flow, we are doing a CPU reset and then loading the example again.

Under normal conditions, the core should start and behave as expected.

However, after the reset, all drivers and the GIC are getting initialized again.
Because of this re-initialization, the expected semaphore signal is not received, which leads to improper synchronization in the second load.

This sequence needs to be checked carefully to understand why the example does not run correctly when loaded the second time after the CPU reset.

By default, the core should start execution from address 0x700000044, but after the CPU reset it is starting from 0x70000040 when the example is loaded again.

This behavior needs further debugging, but it does not impact your current development.

If you want to reload an example, please use system_reset and load an example.

But if you do System_reset from the CCS and load an example again and again, then there is no issue.

Importantly, this issue is not related to the A53 clock configuration.

You can confirm this by reading the A53 core clock each time — the clock remains accurate.

Regards,

Anil.

I'm using the SK-AM62B-P1 EVM, As can be seen in the video, when I use system reset, the debug session shows that the chip enters free-running mode, and the debugger can no longer connect to the chip. From the serial log, I can see that the chip is indeed fully reset, but it starts running from the bootloader, reloading the program from flash, which invalidates the program I had loaded via the debugger. As a result, I need to restart the debug session and enter the same problematic infinite loop again.
Based on your reply: "By default, the core should start execution from address 0x700000044, but after the CPU reset it is starting from 0x70000040 when the example is loaded again." I found that after a normal CPU reset, although it starts from 0x70000040, clicking "run" makes it stop at 0x70000044. However, after loading the program, it also gets stuck waiting for a semaphore.

Hello zegeng Huang,

Recommended Procedure (Temporary Workaround)

Please follow the steps below:
1. Load the example and run it once.
After the example is loaded and starts running, disconnect the debugger.
2. Perform a System Reset.
3. Reconnect the debugger after the reset.
4. Load the example again and run it.

Using this sequence, you will be able to repeatedly load and run examples from CCS without issues.
This is only a temporary procedure to unblock you.

We have identified that the current behavior is not expected — this is a bug and needs to be fixed .

Please find the attached video for you reference..

/cfs-file/__key/communityserver-discussions-components-files/791/A53-Load-.mp4 .

Regards,

Anil.

Hello, I tested this temporary workaround on the SK-AM62B-P1 EVM, and it functions well. Unfortunately, on my custom PCBA, attempting a "system reset" does not reset the device as expected. Instead, it causes the chip to enter UART BOOT MODE, where the processor awaits firmware upload via the serial interface. As a result, the "system reset" function is unavailable. This issue may stem from my PCBA using SOIC-8pin QSPI Flash, which lacks a dedicated hardware reset pin.

Hello, As you mentioned, "We have identified that the current behavior is not expected — this is a bug and needs to be fixed." Could you provide an estimated timeline for when this issue will be resolved? If there is any progress on the fix, please update me via this E2E tick or email at "laixiangjian@appotronics.com" to prevent the problem from being overlooked due to an extended repair period.

Hello zegeng Huang,

zegeng Huang said:

Hello, As you mentioned, "We have identified that the current behavior is not expected — this is a bug and needs to be fixed." Could you provide an estimated timeline for when this issue will be resolved? If there is any progress on the fix, please update me via this E2E tick or email at "laixiangjian@appotronics.com" to prevent the problem from being overlooked due to an extended repair period.

Yes, this needs to be fixed in the MCU+SDK.

Actually, CPU Reset and loading an example will not create an issue.

But this problem we have seen with the A53 cores only and the same problem is not there for other cores like R5F and M4F cores.

I have raised the JIRA to fix this issue and I think that it mostly will take in the next release, i.e. Mar 2026.

I will update the status on the timeline once I get full details from development Team.

Regards,

Anil.

For reference: the difference is:

Disconnect->system reset: works, can reconnect, load and run.

Halt-> System reset: Doesn't work, result in JTAG can't be connected.

Swargam Anil said:

Actually, CPU Reset and loading an example will not create an issue.

But this problem we have seen with the A53 cores only and the same problem is not there for other cores like R5F and M4F cores.

I have raised the JIRA to fix this issue and I think that it mostly will take in the next release, i.e. Mar 2026.

Is this Jira discussed? Is there a target due day? As QSPI flash has not RESET pin, it is not convenient to debug custom board. Not will re-spin board to power of QSPI flash with warm resetout pin to control a power switch, but it is too complex and take time.

If the issue can be fixed in short time, can save the energy. .

Hello Tony ,

As per internal discussion, this Jira bug is going to be fixed in the 12.0 Release.

If the team is fixed earlier, at least I can share the patches.

Regards,

Anil.