• State Resolved
  • Locked Locked
  • Replies 10 replies
  • Answers 1 answer
  • Subscribers 33 subscribers
  • Views 943 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.

nPORRST pin - external reset

Livio Franchin
Intellectual 835 points

Dear all,

I'm using TMS5703137BZWTQQ1 with  TPS65381 as voltage monitor and external watchdog.

I'm not  able to understand if a reset is caused by power up or external watchdog, because bits 15 and 3 of  SYSESR register are both at 1 in both cases.

How can I discriminate the two types of event?? In my opinion, in a safety system it of fundamental importance for the CPU to know when a reset is due to watchdog.

Thank You.

Livio

  • 0
    TI__Genius 9015 points

    Hello Livio,

    I have forwarded your post to one of our experts.  They will respond back soon.

  • 0
    TI__Genius 13810 points

    During the startup, please read the TPS65381 register value to see if any flag is set.

    This is recomended by the TPS65381 safety manual.

    Regards,

    Haixiao

  • 0 in reply to Haixiao Weng
    Intellectual 835 points

    Dear Haixiao,

    Please advise on which page of the mentioned safety manual I can find the recommendation.

    Please note that, if reset is due to watchdog failure, the CPU may not be able to read the register values through SPI interface.

    Anyway, I have read the register values on starting up but the registers that should indicate a watchdog error are cleared by watchdog reset and, therefore, I'm not

    able to realize if there has been a watchdog event.

    Kindly tell me how I can find out if a reset has been caused by a watchdog failure.

    Thank You,

    Livio

  • 0 in reply to Livio Franchin
    TI__Genius 13810 points

    I did some test on my bench and sounds like my understand of the reset was wrong. I will contact the device owner and get back to you.

    Thanks,

    Haixiao

  • 0
    TI__Genius 13810 points

    I discussed with the safety expert of thTps65381. We can not discriminate those two types of event.

    Regards,

    Haixiao

  • 0 in reply to Haixiao Weng
    TI__Mastermind 23000 points

    As all logic in the MCU is cleared by nPORRST, it is not possible to provide state information in the MCU to identify a source of nPORRST.  Any state information in this case must come from an external observer which is not reset during the reset of the MCU.

    Regards,

    Karl

  • 0 in reply to Livio Franchin
    TI__Expert 6985 points

    Hi Livio,

    Except the read of the SAFETY_ERR_STAT register of the TPS65381, it might be possible to add a special key in the RAM to store if the MCU was initialized once before PORRST. This would of cause require, that the RAM is cleared afterwards in the PORRST software sequence and just indicate that there was an PORRST and not the actual reason. In order to be able to get the reason the SPI connection to the TPS65381 has to be established.

    On page 11 of the TPS65381 Safety Manual the following is noted:

    Before transition from DIAGNOSTIC to ACTIVE state, MCU
    must clear WD_FAIL and ERROR_PIN_FAIL flags to 0 (in
    SAFETY_ERR_STAT register) in order not to end-up in SAFESTATE

    This means that you need a working SPI connection in any case if you like to use the TPS65381 in the normal way (ACTIVE state).

    Please also note, that the Watchdog Reset Bit (WDRST, bit 13) in SYSESR only indicates rests caused by the internal watchdog, not by the external.

    Best Regards,
    Christian

  • 0 in reply to Christian Herget
    Intellectual 835 points

    Hi Christian,

    Thank you for your response.

    Sorry to bother, but please explain your concepts in other words and, possibly, in more detail as I'm not able to understand what you mean.

    By the way, I do have a SPI connection between the MCU and the TPS65381.

    Hope to hear from you soon.

    Livio

  • 0 in reply to Livio Franchin
    TI__Expert 6985 points

    Livio,

    If I understood you right, than your aim was to get the reset reason, why the TPS65381 had reset the TMS570.

    In my opinion the only way to achieve this is to read out the TPS65381 via SPI, as only the TPS65381 knows why it has initiated a reset.

    In order to be able to just know if the current PORRST of the TMS570 was the first one or not, you could write a special pattern to the TMS570 RAM after the first PORRST. If you read this location after every PORRST you should be able to determine if the current PORRST was the first or not. This should be possible, as the RAM is not cleared or modified by the PORRST to my knowledge. However the state of the RAM is unknown after the first PORRST.

    I wrote this because of your post saying:

    Livio Franchin said:
    Please note that, if reset is due to watchdog failure, the CPU may not be able to read the register values through SPI interface.

    But I would say, that if the MCU is not able to use the SPI, than the MCU has faced into some serious problems or the physical connection is broken. In both cases I'm not sure, if knowing the exact reset reason has anymore value, but this depends of cause of your system.

    Best Regards,
    Christian

  • 0 in reply to Christian Herget
    Intellectual 835 points

    Hi Christian,

    Thank you for your response.

    Now is all clear.

    Best Regrds

    Livio