• State Resolved
  • Locked Locked
  • Replies 6 replies
  • Subscribers 83 subscribers
  • Views 126 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.

F29H859TU-Q1: Implementing GPIO FFI

Francois Charlot
Mastermind 29237 points

Part Number: F29H859TU-Q1

Hello,

We are looking for some guidance on how to implement FFI on the GPIOs in a system in which some GPIO ports are ASIL-C and others are QM.

The SSU APRs have a granularity of 4KB, thus cannot be used to limit the access on a GPIO port basis.

The GPACSELx registers provide access control at the CPU level, not at the LINK level.

Is there another hardware mechanism that limits a GPIO port access to a specific LINK? If not, which software workaround(s) could you suggest?


Best regards,
François.

  • 0
    TI__Genius 15436 points

    Hi,

    You can give write access to links only that are supposed to configure the GPIO CTRL regs with SSU configuration.

    Even if some ports are QM access should be from link that is supposed to configure gpio ports and other links are not given write access. GPIO Ctrl can only be configured by CPU1 link2 as shown in TRM

    Thanks

  • 0 in reply to Prarthan Bhatt
    Prodigy 30 points
    Thank you for the guidance regarding the GPIO CTRL registers.
    But I'm not sure that answer to my use case, or I misunderstood your answer.
    I understand that write access to the control registers (GPIO configuration) can be restricted using the SSU with LINK2 privileges, but I am concerned about runtime pin access (SET/CLEAR/TOGGLE) for individual pins.
    Consider a scenario on CPU1 with two safety partitions:
    • ASIL Partition: Assigned to LINK2, controlling the GPIOasil pin (GPIO Output).
    • QM Partition: Assigned to LINK3, controlling the GPIOqm pin (GPIO Output).
    In this use case, both pins must be configured to be controllable by CPU1 via the GPySELx register.
    And with this configuration, the QM partition (LINK3) would have the ability to write to the safety pin (GPIOasil) by using GPyDAT, GPySET, GPyCLEAR or GPyTOGGLE registers
    This represents a safety gap in the Freedom From Interference (FFI).
    How can we ensure the FFI on GPIO output pin level by hardware?
  • 0 in reply to Laurent
    TI__Genius 15436 points
    Laurent said:
    the QM partition (LINK3) would have the ability to write to the safety pin (GPIOasil) by using GPyDAT, GPySET, GPyCLEAR or GPyTOGGLE registers

    CPU1 LINK3 doesn't automatically get write permission with this configuration in SSUMODE2. For this you would need to understand how SSU APR configurations work.

    I would recommend referring to  SSU APP note and TRM, C29 CPU reference guide(https://www.ti.com/lit/ug/spruiy2a/spruiy2a.pdf)  chapter on SSU to get started.

    Thanks

  • 0 in reply to Prarthan Bhatt
    Prodigy 30 points
    Hello,
    Sorry, but I am having difficulty seeing how the SSU prevents unauthorized access in this scenario.
    Could you please clarify where my understanding of the following SSU configuration is incorrect?
    For the GPIO, I require:
    • APR range 0x3019_0000 to 0x3019_0FFF: Only LINK2 is granted write access to manage the GPIO configuration.
    • APR range 0x3026_8000 to 0x3026_8FFF (can be extending to 0x3026_9FFF to cover read registers):
      • LINK2 is granted write access to be able to write in GPxSET, GPxCLEAR, and GPxTOGGLE for the GPIOasil pin.
      • LINK3 is granted write access to be able to write in GPySET, GPyCLEAR, and GPyTOGGLE for the GPIOqm pin.
    Because APR ranges have a 4KB granularity and the GPx and GPy registers reside within the same 4KB section, by granted LINK3 the access to write in this range (to be able to drive its GPIOqm pin via GPySET) it appears that LINK3  would also gain the ability to write to GPxSET and drive the GPIOasil pin (which is a safety gap in FFI)
    And if LINK3 is not granted to write in this range, then LINK3 is not able to drive its own GPIOqm pin.
    So please, could you point out where am I wrong  and how SSU can help in this scenario ?
  • +1 in reply to Laurent
    TI__Genius 15436 points

    Yes, if you are looking to give LINK2 and LINK3 both write access to GPIO Data regs then it wont work. You would need to drive GPIO pins which are QM also from LINK2 code. Which mean that the code that's driving pins need to be from safety related code which ensures that its not driven unintentionally since that code will be running on lockstep core.

    Thanks

  • 0 in reply to Prarthan Bhatt
    Prodigy 30 points
    Thank you for the clarification.
    This software solution was the workaround I had in mind if there was no hardware support to isolate the pins.
    Since you have confirmed this is the only way to proceed, we can consider this topic closed.