• State Resolved
  • Replies 7 replies
  • Subscribers 31 subscribers
  • Views 303 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

MCU-PLUS-SDK-AM243X: Usage of GTC

Felix Heil
Expert 1080 points
Part Number: MCU-PLUS-SDK-AM243X

Hello,

we are using the MCU+ SDK 09.00. I just noticed in the TRM and in the SDK there is a GTC. I found it while searchign for a time-checking mechanism which can be used via cores. The driver documentation is really small but at least for us it seems to work to use that via multiple cores. so we can benchmark our call-durations from one core to the other. On the other hand I don't see that used in any of your benchmarking examples. I can only find it somewhere in the sci_client resource management for interrupts.

Is this module functional? we come to like 11 µs for one direct call via RPMessage. This seems to be legit but I wonder why it's not used more times.

How does it behave if I access it from multiple cores? E.g.:

- the init-functionality is not synchronized, is it a problem if I initialize it from multiple cores at startup?

- is the GTC_getCount64() "thread"-safe?

- what happens if one core does a reset like explained in the TRM (which is not implemented in the driver btw.) and another core is reading the value at the same time?

Best regards

Felix

  • +1
    TI__Intellectual 2145 points

    Hi Felix,

    The module is fully functional and below link points to the Test Case, we have for GTC-

    mcupsdk-core/test/drivers/gtc at next · TexasInstruments/mcupsdk-core · GitHub

     - the init-functionality is not synchronized, is it a problem if I initialize it from multiple cores at startup?

    We haven't tried that out yet but looking at the registers being written in the Init code, it seems that shouldn't be a problem.

    - is the GTC_getCount64() "thread"-safe?

    I don't think there is a need for thread safety implementation since there is no read modify write within the API. Atomic read is already handled within the API.

    - what happens if one core does a reset like explained in the TRM (which is not implemented in the driver btw.) and another core is reading the value at the same time?

    This will cause incorrect timer read. Reset should be done only once all cores are aligned for the reset.

    Regards,

    Ashwin

  • 0 in reply to Ashwin Raj
    TI__Guru* 80075 points

    This thread is unlocked per request. However in future you can simply click :"ask related query" and post a new question 

  • 0 in reply to Ashwin Raj
    Expert 1080 points

    Hey Ashwin,

    We just noticed something: It is not possible to initialize the GTC from mutliple cores. at least for us we did not get it to run when booting from flash. CCS-Load is finde but flash-boot brings an abort when writing the registers.

    So we would move the GTC-initialization to the Bootloader. Just as a hint, because the previous statement: "We haven't tried that out yet but looking at the registers being written in the Init code, it seems that shouldn't be a problem." was tried out by us and it doesn't seem to work.

    Best regards

    Felix

  • 0 in reply to Felix Heil
    TI__Mastermind 25370 points

    Hello Felix,

    Felix Heil said:
    We just noticed something: It is not possible to initialize the GTC from mutliple cores. at least for us we did not get it to run when booting from flash. CCS-Load is finde but flash-boot brings an abort when writing the registers.

    Actually, the GTC timer is a very simple timer and any core can do write and read acess there are no issues.

    And one more thing is that the same code is working fine with CCS and not working with the flash. This is strange behavior.

    Please tell me which boot mode you are using when loading an example from CCS ? Is it NO BOOT MODE ?

    Regards,

    Anil.

  • 0 in reply to Swargam Anil
    Expert 1080 points

    Hey Swargam,

    so when we load via CCS it's directly on the same board which booted from flash before. So it's the xSPI-Bootmode that we configured (standard OSPI was somehow not going to work with the flashes we use).

  • 0 in reply to Felix Heil
    TI__Mastermind 25370 points

    Hello Felix,

    Felix Heil said:
    so when we load via CCS it's directly on the same board which booted from flash before. So it's the xSPI-Bootmode that

    I am really don't understand why you are getting data abort when you load example from flash and not with the CCS.

    For example , if you kept the board in NO BOOT MODE and trying to load an example from CCS then there might be a chance SOC is not initlized with any firewalls .So, you don't get firewall issue while loading the example from CCS and if you do load an example from flash definaltey SBL will initlize all firewalls in this case you may get firewall acess issue when you load from flash .

    So, you keep the board in xSPI boot mode, and later you load an example from CCS.

    Actually, this procedure seems OK. In this procedure you should also not have any trouble with file loading from flash instead of CCS.

    For example, if we assume that the GTC has firewall, then you can't access even if it in the CCS or flash loading ..

    One more thing is that you are not using GTC with DMA as well ?

    Can you please share details below, and I the try to reproduce  the issue on my side .

    I hope you are using the same TI SBL .

    On which cores do you want to access GTC ?

    On which basis of stopping the GTC timer ?

    Which core need to start and which core need to stop?

    Please share all details and which  MCU+SDK version are you using  ? 

    Regards,

    Anil.

  • 0 in reply to Swargam Anil
    Expert 1080 points

    Hey Swargam,

    we do not use the DMA with GTC. We only use the API provided in the MCU-Plus SDK.

    We are using the OSPI_SBL as a base but we have modifications for our needs. But we update the bootloader in case of sdk-updates as well with the changes made there.

    We are accessing GTC from mcu0_0 and mcu0_1.

    The next question I do not understand. We are not directly stopping the GTC timer.

    So we are only initializing it via the SDK-function from both cores. Both cores access the GTC reading. We already updated to SDK 09.01

    Regards,

    Felix