J784S4XEVM: SDK example timer is not constantly as expected

Hi,

That's very unlikely, is there anything else running in the system, which is blocking the ISR for longer duration? This could be one reason why ISR is not consistent. 

Regards,

Brijesh

Nothing else is running, I just load the SDK example to EVM board.

The timer is very short, the lowest one is 384us. What is the timer supposed to be in the task switch example ? If it is blocked, it should take longer, not that shorter.

The clock used is default one: HFOSC0_CLK. What is the frequency of this clock ?

Hi Jim,

But once you put breakpoint, it will not remain constant. isn't it? Depending on when this breakpoint is serviced an moved to running state, there could be difference in the timer. If the first interrupt is delayed, then the next interrupt could be shorted, isn't it?

Regards,

Brijesh

The EMUFREE bit is set to 0 in the CFG_TIOCP_CFG register

According the SPRU52, the timer was frozen in debugging mode, the interrupt period should not be impacted

This is the only ISR in the program. It is TI SDK sample program. You should know the code.  Even I put break point in the C handler, result is the same. Can you hook a debugger and run the same sample and check ?  see if you have the same behaviour.

Could you also answer my questions in my previous reply: HFOSC0_CLK. What is the frequency of this clock ?

Thanks,

Hi Jim,

This HFOSC0_CLK is typically from the input OSC0 clock, so it should be same as your input crystal to the SoC.  

Regards,

Brijesh

Hi Jim,

Sorry for the delay. You have no other tasks or applications running correct? Have you tested this example on other cores and replicated this issue?

Thanks,

Neehar

This is a totally TI SDK example. The code is from TI SDK, and I built the application following the SDK instruction, and load the app using scripts provided by TI, and board is J784S4_EVM. Nothing from my side. The app was built for mcu1_0. I don't think it can be executed on other cores.  

I have my own program which behaves the same way, that was the reason that I was verifying it with a pure TI app.

Can you run the same app and check on your side ?

Possible anything relate to the clock configuration?

The TI SDK example uses MCU_TIMER1, clock is HF0_SC0_CLKOUT

MCU_TIMER1 is configured as below:

TLDR value is 0xFFFFB500, it looks like the period is: (0xFFFF-0xB500)/32K = 586ms

How do we make sure that the clock is configured correctly ?

Hi Jim,

Jim Zhang said:

The app was built for mcu1_0. I don't think it can be executed on other cores.  

You can build the app for other cores as well. You can see the cores that you can run the application on by running "make -s freertos_test_task_switch_info" in the build dir.

Jim Zhang said:

How do we make sure that the clock is configured correctly ?

Make sure to add the BOARD_INIT_MODULE_CLOCK to the boardCfg before calling Board_init() to ensure the MCU and Main clocks are initialized properly.

Jim Zhang said:

Can you run the same app and check on your side ?

I have ran the application and see the same period in the ISR from hardware interrupts triggered by HwiP_post() and the semaphore waits.

Jim Zhang said:

I put a breakpoint on the interrupt ISR, the interrupt ISR is supposed to be executed at the timer programmed time, which should be constant. But its period is quite different each time. How could this happen?

Can you elaborate more on what run time you are debugging? It ends at the ISR but where do you start?

Thanks,

Neehar

My breakpoint is HwiP_irq_handler_c(), the timer ISR, it should be executed in the same period as configured.

What is your period from your measurement ? 

Freertos has 3 versions of port.c for cortex r5, in the TI SDK example, which version of the port.c is used ? 

I noticed there are 2 different versions under SDK, I would like to confirm that which version should be used
./pdk_j784s4/packages/ti/kernel/freertos/FreeRTOS-LTS/FreeRTOS-Kernel/portable/GCC/ARM_CRx_No_GIC/port.c
./pdk_j784s4/packages/ti/kernel/freertos/FreeRTOS-LTS/FreeRTOS-Kernel/portable/GCC/ARM_CR5/port.c

Thanks,

Jim

Any progress on this issue ?  Could you answer all my questions after you last comments (I list them again below)?

In the example,

1: what is the interrupt period for the MCU_Timer1?

2: What is the default clock for MCU_TIMER0, even it is not used ?  Is it !GHHz/4 ?

3: What version of the freertos used in the example ?

4: The SVC exception handler should be around 0x0 as configured by SCTLR, how could it be set to 0x8005xxxx in the example ?

5: Is J784S4 r5f supported by the latest FreeRTOS LTS release 202406-LTS ?   If Yes, which version of freertos is suitable for this processor ? In freertos release 202406-LTS, there are 3 versions available:

drwxr-xr-x 1 zhangz1 1049089 0 Feb 7 16:26 ARM_CR5/
drwxr-xr-x 1 zhangz1 1049089 0 Feb 3 10:17 ARM_CRx_MPU/
drwxr-xr-x 1 zhangz1 1049089 0 Feb 3 10:17 ARM_CRx_No_GIC/

If you think that I need ask some questions in a separate thread, please let me know; I will ask in new thread

Hi Jim,

Jim Zhang said:

What is your period from your measurement ? 

I will need to perform tests to get the exact period, however, my initial tests were about 2 microseconds.

I will look deeper and follow up with answers to your remaining questions tomorrow.

Thanks,

Neehar

Shouldn't the period be calculated like below?

(0xFFFFFFFF - TLDR value)/HF0_SC0_CLKOUT

TLDR value is 0xFFFFB500, it looks like the period is: (0xFFFFFFFF-0xFFFFB500)/(32K) = 586ms

Please also let me know the correct calculation method from the register values

Thanks

Hi Jim,

Jim Zhang said:

Freertos has 3 versions of port.c for cortex r5, in the TI SDK example, which version of the port.c is used ? 

I noticed there are 2 different versions under SDK, I would like to confirm that which version should be used
./pdk_j784s4/packages/ti/kernel/freertos/FreeRTOS-LTS/FreeRTOS-Kernel/portable/GCC/ARM_CRx_No_GIC/port.c
./pdk_j784s4/packages/ti/kernel/freertos/FreeRTOS-LTS/FreeRTOS-Kernel/portable/GCC/ARM_CR5/port.c

You can find the file at the following location: <PDK_INSTALL_PATH>/packages/ti/kernel/freertos/portable/TI_CGT/r5f/port_r5f.c

Jim Zhang said:

2: What is the default clock for MCU_TIMER0, even it is not used ?  Is it !GHHz/4 ?

All MCU_Timern instances have HFOSC0_CLK by default unless MCU_TIMERn_CLKSEL_clk_sel[2:0] is manipulated otherwise.

Jim Zhang said:

3: What version of the freertos used in the example ?

What SDK are you using? SDK 9.2 and later uses FreeRTOS kernel 10.5.1.

Jim Zhang said:

4: The SVC exception handler should be around 0x0 as configured by SCTLR, how could it be set to 0x8005xxxx in the example ?

Let me look into register further and get back to you.

Jim Zhang said:

5: Is J784S4 r5f supported by the latest FreeRTOS LTS release 202406-LTS ?   If Yes, which version of freertos is suitable for this processor ? In freertos release 202406-LTS, there are 3 versions available:

We have tested and support FreeRTOS LTS release 202210-LTS. It has not been validated on 202406-LTS.

Jim Zhang said:

(0xFFFFFFFF - TLDR value)/HF0_SC0_CLKOUT

TLDR value is 0xFFFFB500, it looks like the period is: (0xFFFFFFFF-0xFFFFB500)/(32K) = 586ms

Please also let me know the correct calculation method from the register values

Yes, this is correct given TIMER_TCLR[5] PRE bit set to 0. I was simply testing the frequency of ping or pong ISR getting called.

Thanks,

Neehar

MCU_TIMER1~10 default to HFOSC0_CLK, but MCU_TIMER0 default to MCU_SYSCLK/4, you can check the clock config from debuger.

If my calculation is right, the period is 586ms; I think your test results differ from my calculation. Could you explain 

Thanks

I am using following scripts to load the and run the app, but task switch is not happening. I put break point at ping_main/pong_main(), the break points never hitcmm-tda4vh_j784s4.zip

The scripts I ran is: D:\cmm-tda4vh_j784s4.zip\cmm-tda4vh_j784s4\x_gel_to_cmm\pdk_rtos_test\cat_launch_freertos_r5.cmm

The elf file is under D:\cmm-tda4vh_j784s4\freertos_test_task_switch_mcu1_0_release.xer5f

I would like to make sure that the app I built is correct, and the way I launch the app and run the app is correct

Please also provide the elf built from your side, and I would like to run it on my device to compare.

Thanks

Jim,

Jim Zhang said:

MCU_TIMER1~10 default to HFOSC0_CLK, but MCU_TIMER0 default to MCU_SYSCLK/4, you can check the clock config from debuger.

MCU_TIMER0 will be set to MCU_SYSCLK/4 if MCU_TIMERn_CLKSEL_clk_sel[2:0] is manipulated and set to 1. Otherwise the default value is still 000 or HFOSC0_CLK.

Sorry, I'm not familiar with the files in the zip you provided. How are you booting the EVM?

Additionally, can you provide how you are building the example? Are you using the PDK based build system?

What SDK version are you using? I can provide the binary to see if there are any discrepancies. 

Thanks,

Neehar

Neehar:

Yes, please provide the binary you built; I am using SDK 10.01

build steps:

cd ~/sdk-rtos-j784s4/pdk_j784s4/packages/ti/build$

make -s all BOARD=j784s4_evm SOC=j784s4 BUILD_PROFILE=release CORE=mcu1_0 BUILD_OS_TYPE=freertos

The most important info I need know is how you calculate the period from the register values; I sent an email to TI coordinate, and I copy the email below

I would like to get answer from you on step 3 and step 4.

Thanks

Summary:  I am waiting for info below:

1: Please provide your binary for me to check

2: The timer period calculation method from MCU timer registers (step3), and calculation result

3: The way you verify that your timer interrupts at the calculated period

Thanks

Hi Jim,

I have attached the binary below:

https://e2e.ti.com/cfs-file/__key/communityserver-discussions-components-files/791/freertos_5F00_test_5F00_task_5F00_switch_5F00_mcu1_5F00_0_5F00_release.appimage

https://e2e.ti.com/cfs-file/__key/communityserver-discussions-components-files/791/freertos_5F00_test_5F00_task_5F00_switch_5F00_mcu1_5F00_0_5F00_release.xer5f

https://e2e.ti.com/cfs-file/__key/communityserver-discussions-components-files/791/freertos_5F00_test_5F00_task_5F00_switch_5F00_mcu1_5F00_0_5F00_release_5F00_strip.xer5f

I will get back to you this week about the measured timer period.

Can you confirm how you are running the binary and booting the board?

Thanks,

Neehar

I power up the board, and run the scripts D:\cmm-tda4vh_j784s4.zip\cmm-tda4vh_j784s4\x_gel_to_cmm\pdk_rtos_test\cat_launch_freertos_r5.cmm I uploade last time to run the app

I checked your binary, result is same. There is only one irq mcu_timer1. Verified each time only this IRQ is triggered, but the time between 2 ISR execution is different. Possible the way I measure the timer is incorrect ?  When I stopped program in debugger, the timer counter is not frozen, it still increases, could that impact the measurement.

I enabled/disable the EMUFree bit, it does not impact the counter. Is there a way to freeze the timer counter when the program stopped by debugger ?

Thanks, 

Hi Jim,

Jim Zhang said:

When I stopped program in debugger, the timer counter is not frozen, it still increases, could that impact the measurement.

This could possibly be the reason why you are seeing arbitrary values. Are you profiling the time difference between ping ISR and pong ISR? Or testing the difference in time between ping ISR being called twice?

You can manually start/stop the timer using the timer control register TIMER_TCLR[0]. Setting TIMER_TCLR[0] to 0 will freeze the counter until set to 1 again.

Thanks,

Neehar

I knew how to start and stop timer; I want to know why the EMUFREE bit is not working. The counter is supposed to stop in debug mode

This is very good info. I will add Data.Set EAPB:0x9D3001A8 %LE %Long (0x10000|17.) to  _J784S4_r5.cmm and enable EMUFREE bit, and check.

This is an issue in my application; but when I ran this TI SDK sample app, it has similar issue. So I use this app to get support and figure out my app issue 

sorry, could you re-open this issue?  We made big progress, but still have more questions regarding this test app. I put break point at HwiP_irq_handler_c and HwiP_irq_handler, and execution the program. I found that in one interrupt cycle, HwiP_irq_handler_c is executed twice, but HwiP_irq_handler is executed once. Why HwiP_irq_handler_c is executed twice? It should matching the HwiP_irq_handler execution times

The test binary you provided does not have the issue above.  Which version of SDK did you use to build your binary ? I use Processor SDK RTOS J784S4 10_01_00 to build the app.  

This app is supposed to test task switching, but from my test, the execution is not switching between tasks. Although the task list it shows freertos_main is running, I put break points at ping_main() and pong_main, I did not find those break points were hit

Also the period, from my calculation, the period should be

(0xFFFFFFFF - TLDR value)/HF0_SC0_CLKOUT

TLDR value is 0xFFFFB500, it looks like the period is: (0xFFFFFFFF-0xFFFFB500)/(32K) = 586ms

From the test with your binary, the period is about 1.5ms, why the period is different from my calculation ?

Hi Jim,

Following up, is this issue still open?

Thanks,

Neehar