• State TI Thinks Resolved
  • Locked Locked
  • Replies 6 replies
  • Answers 3 answers
  • Subscribers 30 subscribers
  • Views 887 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.

RM57L843: EXTRST and PORST bits in SYSESR register

Chetan Chavan
Intellectual 265 points

Part Number: RM57L843
Other Parts Discussed in Thread: HALCOGEN

Hi!

All the ambiguity that I have regarding nRST pin would be solved if the following questions are answered separately..

1.) Whenever I am doing "Software Reset" (using the SYSECR register), should I be expecting the nRST pin to give a low pulse as an output? If yes, why? Does "EXTRST" bit in SYSESR register also SET whenever I do Software Reset along with "SWRST" bit?

2.) After performing a warm reset by either "Software Reset" or by driving nRST pin low through an external source (say watchdog), the contents of the RAM (lets say global variables defined and stored with some intermediate values until warm reset) should be retained unless I perform "Memory Initialization" in my startup code right?

3.) Is there any way/or_by_chance so happens that triggering nRST low through an external source for warm reset also sets the PORST bit in SYSESR register?

After having given the answers to the above question, please read my observations as under: (Experiments performed on a custom board - RM57L843 controller)

1.) Whenever I perform "Software Reset", I observe that both "EXTRST" and "SWRST" bits in SYSESR register are SET and not just "SWRST". I also see that "nRST" pin remains HIGH and does not give a low pulse upon "Software Reset". However, I feel that nRST pin should be going LOW (pulse) whenever I do "Software Reset".

2. and 3.) I am driving "nRST" low via a watchdog circuit (external watchdog) during normal running. After this, when I read the SYSESR register, I observe that "EXTRST" and "PORST" (power_on_reset bit !!) are both being SET which should not be the case at all! The contents of the RAM are also getting lost (global variables) even though I bypassed memory Initialization in startup code.

Firstly, I need some clarity on the conditions when nRST pin is driven low (low pulse) either internally by the controller (since it is bi-directional pin) or what happens when I drive it low externally through a watchdog etc.

Secondly, what is the connection between EXTRST, SWRST, PORST in the SYSESR register? I have gone through the TRM of RM57 several times, so please give me any other source for reference if at all there exists. Basically, SWRST/OSCRST/WATCHDOG/WINDOWED_WATCHDOG should also SET the "EXTRST" bit in SYSESR register. The PORST bit only sets upon "Power-On" and nothing else (I dont have any external voltage monitoring circuit to drive PORRST pin). I have a pull-up resistor on nRST pin but not in PORRST pin (which I know is recommended but anyways, the above said conditions/scenarios should not be occurring irrespective of whether PORRST pin is pulled up or not externally).

Thanks and Regards,

Chetan.

  • 0
    TI__Mastermind 49120 points

    Hello,

    nRST is a bi-directional terminal. Externally it requires to be pulled up to 3.3V. This terminal is driven low as an output on ALL system reset conditions. This terminal can be driven low externally to also assert system reset to the part. The timing specifications / requirements for both the output / input functions of this terminal are specified in the datasheet. This answers the questions:

    1. how long is the nRST terminal driven output low on an internally-detected system reset, and
    2. how long does an external circuit need to drive the nRST terminal low in order to cause a system reset to the part

    Answers to your specific questions:

    Chetan Chavan said:

    1.) Whenever I am doing "Software Reset" (using the SYSECR register), should I be expecting the nRST pin to give a low pulse as an output? If yes, why? Does "EXTRST" bit in SYSESR register also SET whenever I do Software Reset along with "SWRST" bit?

    Yes, nRST is driven output low on ALL system reset conditions, including software reset. EXTRST bit in the SYSESR register is set whenever the nRST terminal is driven low, either by an internally-generated system reset condition (as an output function) or by driving nRST low externally (as an input function).

    Chetan Chavan said:

    2. and 3.) I am driving "nRST" low via a watchdog circuit (external watchdog) during normal running. After this, when I read the SYSESR register, I observe that "EXTRST" and "PORST" (power_on_reset bit !!) are both being SET which should not be the case at all! The contents of the RAM are also getting lost (global variables) even though I bypassed memory Initialization in startup code.

    Please confirm which reset input is driven by the external watchdog circuit. The behavior you describe indicates that the nPORRST input is being driven low by the watchdog circuit. RAM contents being lost is usually a software function unless it is caused by a real power loss. There must be a function call to initialize the L2 RAM on power-up, so this is what could be causing the RAM contents to be lost.

  • 0 in reply to Sunil Oak
    Intellectual 265 points

    Hi Sunil!

    Thanks for the reply! As per the datasheet, the minimum time is 0.457us and maximum is 2us. As per what you said, the fact that EXTRST bit is being SET on "Software Reset" in my case confirms that nRST terminal is being driven LOW (as an output). However, I could not observe it in CRO.

    As far as the RAM contents are concerned, I am having a software function to initialize the L2 RAM on power-on but even then I see that the contents are lost. Therefore, I also tried by bypassing that initialization function as well. However, when I write anything in the following locations:

    0xFFF8C04C and 0xFFF8C048, the value is being retained after a "Software Reset". That memory range is "System Peripherals - Frame 1" as per memory map of the controller.

    Yes, the behavior I described feels like the PORRST pin is being driven by watchdog rather than nRST. But, its nRST only and not PORRST pin. We do have a pull-up on nRST and now we are connecting a pull-up to PORRST as well. I will re-try and post my results here.

    Regards,

    Chetan.

  • 0 in reply to Chetan Chavan
    Intellectual 265 points

    Hi!

    So, here are the updates! My PORRST pin and nRST pin seems to be shorted (tracks on PCB layout) and that is why I was facing the problems mentioned above.

    That being the root cause, I have an understanding of the concept now. The above two memory locations belonged to "System Peripheral RAM" which would not get initialized like L2 RAM upon software reset and therefore retained contents. However, upon an external reset (via a watchdog) which was also causing a power on reset (because of tracks getting short, observed low pulse on both nRST and PORRST pins), I want to know whether such a cold reset all clears the peripheral RAM as well?

    Regards,

    Chetan.

  • 0 in reply to Chetan Chavan
    TI__Mastermind 49120 points

    Hi,

    Glad you found the issue. As I mentioned, unless there is a real power loss causing memory contents to become random all memory clearing mechanisms are initiated by software. As you mentioned in your (previous post -1), you do call the memory initialization sequence whenever a power-on-reset is detected.

  • 0 in reply to Sunil Oak
    Intellectual 265 points

    Hi!

    Does the "_memInit_()" function in startup.c, generated by Halcogen clear both the L2 RAM and System Peripheral RAM? 

    Best,

    Chetan.

  • 0 in reply to Chetan Chavan
    TI__Mastermind 49120 points

    The _memInit_() routine generated by HALCoGen uses the built-in hardware mechanism for memory initialization. This specific routine only initializes the L2 RAM.