• State Resolved
  • Replies 18 replies
  • Subscribers 98 subscribers
  • Views 455 views
  • Users 0 members are here
Support feedback
Options
Options
Related

AM6442: Profinet Sample Application - OSAL - Task Notification Delay

Upendar Sama
Prodigy 235 points
Part Number: AM6442
Other Parts Discussed in Thread: SYSCONFIG

Hello,

I am trying to trigger a previously created High Prio(OSAL_TASK_Prio_30) Task every 1ms using GP Timer Compare Match ISR Callback. 

void Callback(GPTIMER_Handle handle)
{
    //OSAL_EVT_set(l_pTaskEvent);

    BaseType_t xHigherPriorityTaskWoken = pdFALSE;
    vTaskNotifyGiveFromISR(gTaskHdl, &xHigherPriorityTaskWoken);
    portYIELD_FROM_ISR(xHigherPriorityTaskWoken);

    //OSAL_postSignal(l_pTaskSignal);
}

Only in Profinet Sample Application, task trigger is delay by 500 - 600 us sometimes. I have tested the same approach in a simple freertos application and Notification to Task Activation delay is less 10us.

This task has highest priority. I don't understand which Task/ISR causing the delay in this task activation.

Please help.

Thank you.

Best Regards,
Upendar Sama

  • 0
    Prodigy 235 points

    Hello,

    I have made one more observation. 

    The above mentioned delay in task triggering occurs only when the PLC - IO Device Communication is active. So How can i control the priority of the PRU --> R5 ISR priority?

    Regards,
    Upendar Sama

  • 0 in reply to Upendar Sama
    TI__Intellectual 1420 points

    Hi Upendar,

    for the time being we don't provide an API to control the task priorities and they are fine-tuned to provide the best performance for our platform. However, if you take a look at the runtime object view of your project on Code Composer Studio you should find that the task priorities of PROFINET stack have priorities less than 30. 
    I will try to replicate your scenario with the high priority task and follow-up on this issue.

    Thank you.
    Kind regards,
    Kamil

  • 0 in reply to Kamil Alkhouri
    Prodigy 235 points

    Hi Kamil,

    Thank you for the response.

    I just want to create a 1ms or 500us task using hardware timer. Please try to reproduce this with and without PLC to IO Device Communication.

    Best Regards,
    Upendar Sama

  • 0 in reply to Upendar Sama
    TI__Intellectual 1420 points

    Hi Upendar,

    I tried to quickly produce a similar scenario and used OSAL_EVT to trigger the high priority task from the ISR callback. I initially do not observe any delay in the task performance (I'm toggling a GPIO PIN to measure it). I will try to use the vTaskNotifyGiveFromISR instead and get back to you.
    Meanwhile, would you please share a list of the tasks running on your side and their priorities? You can obtain this from Runtime Object View on Code Composer Studio.

    Thank you.
    Kind regards,
    Kamil

  • 0 in reply to Kamil Alkhouri
    Prodigy 235 points

    Hi Kamil,

    Interesting. I have only created few other tasks, all with priority less than 30. Just to make sure, what is the IO Cylce Update time in PLC? I am using 1ms.

    Regards,
    Upendar

  • 0 in reply to Upendar Sama
    TI__Intellectual 1420 points

    Hi Upendar,

    I'm also using 1ms cycle time and I tried it both with RT and IRT.
    1. Maybe you can try to temporarily disable the tasks and see if that affects the performance?
    2. What's the interrupt priority of the GPTIMER on your sysconfig?
    3. Is the stack of your high priority task stored in a cached memory region?

    Thanks.
    Kind regards,
    Kamil

  • 0 in reply to Kamil Alkhouri
    Prodigy 235 points

    Hi Kamil,

    1. I can try but I am not optimistic. I have observed the delayed task activation only after the Link established with PLC. I disconnected the cable and checked this point. 

    2. I set it to 4. I thought this could be the reason and changed all the other ISRs prio to 5 and checked it. But no change in the performance.

    3. Yes. 

    would it be possible for you to share your project? I am using Ind Comm 11_00_00_08. 

    Regards,
    Upendar

  • 0 in reply to Upendar Sama
    TI__Intellectual 1420 points

    Hi Upendar,

    sure!
    However, in order to easily build the project, I recommend you to install our latest SDK (2025.00.00.08) and it's corresponding MCU+ SDK and code composer studio. Afterwards you can replace the three default files provided in our demo (main.c, pn_app_iod_data.c and example.syscfg) with the ones available under the following link.

    Files: https://tidrive.ext.ti.com/u/9EyIIXFMiCzmTIg8/ac375810-6783-4989-bbb6-df64fbb73577?l
    Access code: `9pq2zrF

    Alternatively, you can take a look at the files (the diff is quite small) and integrate the changes manually inside your project.

    Kind regards,
    Kamil

  • 0 in reply to Kamil Alkhouri
    TI__Intellectual 1420 points

    Hi Upendar,

    FYI, I also obtained the same very good accuracy using xTaskNotifyFromISR().
    Hopefully you have now enough input from my side to move forward. 

    Thank you.
    Kind regards,
    Kamil

  • 0 in reply to Kamil Alkhouri
    Prodigy 235 points

    Hi Kamil,

    Thank you.

    I used the unmodified Profinet sample application to test it. I have observed same behaviour with this one also. But I have not used the latest SDK. I don't this it will change this behaviour.

    I have attached the screenshot of the gpio outputs. First one is the from the High Prio Task and second one is from the GP TImer callback. 

    In PLC Project, TI IO Devices uses 2ms as default IO Cyclie time. When I changed it to 1ms, the problem appeared. Please recheck the cycle time.


    And I wanted to check if Runtime Object View could be useful for debugging, but when I started it for my profinet project, I can only see Monitor. There are no OS Kernel modules. How do i enable them?

    Regards,
    Upendar Sama

  • 0 in reply to Upendar Sama
    TI__Intellectual 1420 points

    Hi Upendar,

    I confirm configuring 1ms cycle time on the IO device and still seeing no issue.

    Using ROV should be straight forward. Just open ROV window after running your application, set the module name to "FreeRTOS" and the view name to "Task Instances", pause your running program and wait for a while until CCS processes the data and lists the tasks. 
    If you don't see the options I mentioned, please share your CCS version and syscfg_c.rov.xs file (this file should be directly inside the project's workspace). It also makes sense to use the latest CCS available on TI website.

    Based on the picture you shared, it looks like the unwanted delay does not happen every cycle and it is not periodic. This might be the reason I don't easily see it on my oscilloscope. I'm also running my tests on an AM243 (should be similar to AM64), but I will verify this on my side as well.

    Thank you.
    Kind regards,
    Kamil

  • 0 in reply to Kamil Alkhouri
    TI__Intellectual 1420 points

    Hi Upendar,

    I tried to run the program I shared with you yesterday on an AM64 and it was ok. Would you please share ROV output? Have you checked the CPU load on your side? if you're using our demo, it should be much less than 10%.

    Thank you.
    Kind regards,
    Kamil

  • 0 in reply to Kamil Alkhouri
    Prodigy 235 points

    Hi Kamil,

    Thank you for continued support.

    I have attached the screenshots for the ROV Task View and waveform at the moment of unknown dealy.

    One idea to really identify the unknown delay is to measure the time between each task trigger inside the task function. 

    Regards,
    Upendar Sama 

  • 0 in reply to Upendar Sama
    TI__Intellectual 1420 points

    Hi Upendar,

    please take a look at my oscilloscope output below. The delay between the signal edges is way less than the values measured on your side. Since you are using the same default example I provided, I advise you to work with the latest SDK. Based on some internal discussion, we suspect that an MCU+ SDK bug that was resolved in the latest release could be the reason for the behavior you see.

    Would you please try installing ind_comms_sdk version 2025_00_00_08? the installer will ask to automatically trigger the installation of mcu_plus_sdk version 11_01_00_17 which should have the fix we need.



    Kind regards,
    Kamil

  • 0 in reply to Kamil Alkhouri
    Prodigy 235 points

    Hi Kamil,

    Ok. I will try with latest SDK and comeback to you. 

    Thank you.

    Regards,
    Upendar

  • 0 in reply to Upendar Sama
    Prodigy 235 points

    Hi Kamil,

    I have checked with latest SDK and results are better. At few instances, i found some abnormalities but not like earlier long delays. I cannot test my main application with new sdk which requires additional work. So, for now, I will mark this as resolved. if I find more problems, then I will create a new ticket. 

    Thank you for the support.

    Regards,
    Upendar Sama