• State TI Thinks Resolved
  • Locked Locked
  • Replies 5 replies
  • Answers 1 answer
  • Subscribers 30 subscribers
  • Views 1398 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.

TMS570LC4357: Peripheral power down mechanism

Gael Le Moing
Expert 1020 points
Part Number: TMS570LC4357
Other Parts Discussed in Thread: HALCOGEN

Hi,

After reading all the documentation and forum topics I could find, I understand how the bits in the PCRx PSPWRDWNCLRx and PSPWRDWNSETx registers work.

After some testing with the microcontroller, it seems that even if the clock to a peripheral is inactive, I am able to write into the peripheral registers (under PCR3).

In our design, the CPU is connected to a FPGA and the FPGA performs some trace on MibSPI2 CS0 transactions from the CPU (CPU IOMM is configured accordingly). What I see is that when I let the PSPWRDWN registers in their reset state (where Quadrants Quad2 and Quad3 of PS[2] clock is inactive), the FPGA is able to see transactions from the CPU when it sends 16 bits of data via SPI. The data is incorrectly interpreted, but as it detects transactions that means that the Chip select is driven acording to an SPI transaction. I was expecting that if the MibSPI2 were not clocked, as supposed by the PSPWRDWN configuration, the MibSPI2 could not output any signal or even the access to its registers wouldn't be possible.

So I have some questions related to this topic:

  • On reset, PSPWRDWNCLR3 bits 31-24 are cleared to 0 (clock active), but documentation says their reset value is "1". These bits correspond to PS[31] and PS[30] which are the PCR3 registers, according to the Memory map table of the TRM. I tried to set the clock inactive by writing 0xFF000000 to PSPWRDWNSET3 register, but it has no effect. Is this something I missed in the documentation (TRM, datasheet, errata) or is it a bug?
  • What should we expect when setting a peripheral clock inactive? What is the difference with setting the clock active?
  • If using a module only for GIO function (GIO, DCAN, MIBSPI, RTP, DMM, LIN), do we need to set the peripheral clock active or is ti supposed to work if we let it inactive? Why?
  • What advantages could we get from disabling peripherals clock (for a safety critical application analysis, as example)?

Thanks for your support.

Best regards,

Gael

  • 0
    TI__Guru 59540 points
    Hello Gael,

    First, my apologies for the delay in getting back to you. We have been unable to reach our office over the past week due to impact of Hurricane Harvey on the Houston, Tx. area and our office will remain closed until next Tuesday, Sept. 5th. This limits my ability to check with some of our device experts to get an in depth answer to your question.

    I recall some discussion with our experts about clock gating and the cancelation of the power down event if ongoing activities/accesses cause a timeout of the power down request. However, I am not confident in this answer and need to check with some of our experts on it. I will do so next week provided they are able to return to work also. My apologies in advance if there are any further delays after that point.

    I also thank you for your patience in these very difficult times for our area and for many of our team members impacted by the storm and the flooding.
  • 0 in reply to Chuck Davenport
    Expert 1020 points
    Hi Chuck,

    Thanks for the update.

    Best regards,
    Gael
  • 0 in reply to Gael Le Moing
    Expert 1020 points
    Hi,

    Any news?

    Best regards,
    Gael
  • 0
    TI__Guru 59540 points

    Gael,

    My apologies for the long delay in getting back to you. Unfortunately your question fell through the cracks as we were getting caught back up. None, the less, I assume you still have the same question.

    Gael Le Moing said:
    What should we expect when setting a peripheral clock inactive? What is the difference with setting the clock active?

    To clarify, the PSPWRDWN bits in the PCR are used to put a module into a state of reset. In this case the clocks will be gated to these modules and they will not be clocked. However, if the CPU makes an access to them, they will be temporarily clocked for the singular access but then gated again after the access. The specific point I wanted to clarify is that these bits do not disable the clock domains which are enabled/disabled via the clock domain set and clear registers.

    In regard to the PSPWRDWNCLR3 bits 31-24, these should be disabled at power up but be careful in where you check them because the boot code from Halcogen probably does a global peripheral enable causing all peripheral domains to be enabled. If you, in fact confirm the descrepancy, please use the document feedback link in the TRM to note the issue and bug against the document will be generated for our documentation department.

    Gael Le Moing said:
    I tried to set the clock inactive by writing 0xFF000000 to PSPWRDWNSET3 register, but it has no effect. Is this something I missed in the documentation (TRM, datasheet, errata) or is it a bug?

    Double check the status of the PPROT registers to insure you are able to write to the PCR3 registers in the current mode of operation.

    Gael Le Moing said:
    If using a module only for GIO function (GIO, DCAN, MIBSPI, RTP, DMM, LIN), do we need to set the peripheral clock active or is ti supposed to work if we let it inactive? Why?

    Whenever you are actively using the logic within an IP it should be enabled via the PCR registers and released from reset (sometimes locally in the module as well as at the system level in the PCR registers). The use of the module in GPIO mode only is achieved by configuring the pins in non-functional mode. i.e., the primary function is disabled allowing general use as GPIO.

    Gael Le Moing said:
    What advantages could we get from disabling peripherals clock (for a safety critical application analysis, as example)?

    The primary advantage of using the system level power down mechanism or even the local reset/powerdown mechanisms is that the module can then be considered off line and you are freed from the burden of proving non-interference with your safety function.

  • 0 in reply to Chuck Davenport
    Expert 1020 points
    Hi Chuck and thank you for your answers.

    Just to clarify some points on the context: I developed the code and it doesn't use HALCOGEN code. The ARM mode is Supervisor.

    I need some clarifications on some points:
    - As I understand, disabling the clocks of a peripheral in the PSPWRDWN registers will prevent the module to perform any action by itself (as its clock is gated), but the CPU is still able to perform transactions to the module registers event if the module clocks are gated. RIght?
    - For PSPWRDWNSET3 bits 31-24: I was aware of the PPROT and PsxMSTID registers, but in my code I have let them in their reset state . Unless there is a constraint for PCR3 registers stating that its clocks can't be deactivated? If not, is this an issue of the TMS570?
    - As far as I understand, there are 3 ways of disabling a module: the Power domain disable mechanism (through PMM), the system level power down mechanism (through PCR registers) and the local module disable (through the module registers) if available. What differences does that make to use one method or another? In case one is used and not the others, what occurs if the CPU tries to read or write to a register intended to be disabled? In each case, does the module be able to perform actions un-intentionnally?

    Best regards,
    Gael