• State
  • Locked Locked
  • Replies 5 replies
  • Subscribers 31 subscribers
  • Views 329 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

AM2434: AM2434 - Realization of SCIdriver - DMSC as stated in MCU+ SDK

Oliver Koepcke
Prodigy 20 points
Part Number: AM2434

Going through the API documentation (https://software-dl.ti.com/mcu-plus-sdk/esd/AM243X/08_06_00_45/exports/docs/api_guide_am243x/group__DRV__SCICLIENT__MODULE.html) of sciclient suggests that it is possible to configure the driver to be RTOS aware and interrupt based. (https://software-dl.ti.com/mcu-plus-sdk/esd/AM243X/08_06_00_45/exports/docs/api_guide_am243x/group__SCICLIENT__HAL.html)



Looking at the source code the driver only supports polling based bare-metal operation contrary to what the documentation states. A driver which does polling inside of a critical section can have severe side-effects on RTOS based projects. 
We found an implementation of the driver with server/client architecture as part of the Jacinto7 PDK. Is it planned to port this functionality also on Sitara architecture?
Jacinto7 PDK https://software-dl.ti.com/jacinto7/esd/processor-sdk-rtos-jacinto7/06_01_01_12/exports/docs/pdk/docs/user_guide/html/group__SCICLIENT__HAL.html

If not, is it guaranteed to receive a response from DMSC in a specified time? Is information available for latency introduced by sciclient polling?

Thank you for your support

Oliver

  • 0
    TI__Expert 8165 points

    Hi Oliver,

    First of all, apologies for the miscommunication in the user guide, we only do support polling mode in Sciclient as you have seen from the source code. This will be corrected in the upcoming release. However, implementing interrupt mode is not planned for the immediate release. The scilcient implementation in Jacinto can be confusing, although I think the interrupt mode is enabled there. The sciserver/sciclient architecture you might have seen is applicable only for the Jacinto class of devices because of the split architecture. For AM243x there is only one firmware which runs on the DMSC core to which the sciclient will talk. So there is no need for sciserver. 

    Regarding the latency of polling, it actually depends on the type of request made to the SYSFW. If it is a simple enable/disable module or a version check, It is mostly in the order of microseconds. More complex requests like interrupt routing will take more time. I will see if I can get a latency table of sorts for typical requests.

    Let me know if you have any more queries regarding Sciclient.

    Regards,
    Anand Mahadevan SS

  • 0
    Prodigy 20 points

    Hello Anand,

    Thank you for your clarification. For our design an idea about different latency times are useful. With this we are able to define a maximum timeouts for each kind of a request to prevent hanging requests or permanent occupied resources. Thank you for your support.

    Oliver

  • 0 in reply to Oliver Koepcke
    TI__Expert 8165 points

    Hi Oliver,

    I am checking with the SYSFW team if there is a table available. If the data is not readily available, I can try profiling specific requests and can provide you with the data. This might take some time, so if you let me know a ballpark of which functionalities you're particularly looking forward to, I can check those in priority and get back to you with the data.

    Regards,
    Anand Mahadevan SS

  • 0 in reply to Anand Mahadevan SS
    Prodigy 20 points

    Hi Anand,
    that fits for us as you described your next steps. We will integrate this times in our architecture. Additionally  if no data or example is present now: Can you give us an idea of the worst maximum time the complicated request needs for preparing an answer. That would be helpfull for the design.
    Thank you and "see" you

    Oliver

  • 0 in reply to Oliver Koepcke
    TI__Expert 8165 points

    Hi Oliver,

    Apologies for the late response. Unfortunately there is no such data readily available, and there are a lot of APIs to profile. Since you have asked for a worst case scenario, I think the maximum time would be taken by a Processor Boot request. Usually it takes few 100s of milliseconds, typically 200-300 ms. But processor boot is a very specific API call, usually used only in bootloader context. And the time taken is reflective of the size of image to be loaded on a core etc. In case of general purpose Sciclient calls like power management, clocks or interrupt routing, the latency is typically sub-millisecond. Hope this helps, let me know if any further information is required.

    Regards,
    Anand Mahadevan SS