• State Resolved
  • Locked Locked
  • Replies 2 replies
  • Subscribers 78 subscribers
  • Views 1393 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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.

RTOS/MSP432P4111: Resets in the MSP432

Julian Kolodko
Expert 2265 points

Part Number: MSP432P4111

Tool/software: TI-RTOS

G'Day all,

Could anyone give me some clarification about the various resets in the MSP432?

  1.  According to the Technical Reference (SLAU356H, Section 2.3) both hard and soft resets are initiated under user application control.  If this is strictly true, and only the user application can cause soft or hard resets, then why do the lists of reset sources in the data sheet (SLASEA0A, section 6.8.1) specify only hardware reset sources or reserved and do not allocate a single user reset source?
  2. Will the device be automatically reset if a given reset source fires, or does the user application somehow have to intervene or enable something before the reset occurs?
  3. Can soft/hard resets be turned off, or forced to act as Reboot resets?
  4. The description of hard and soft reset says "returns control to the user code".  What does this mean?  Does the processor just continue on from where it was? Restart from address 0? From the reset vector?
  5. What is the difference between using the SYS_RESET_REQ register to perform a reboot (the Technical manual seems to refer to using this register to reboot the device, but driverlib does not define that as a register under the SYSCTL_A-> name space so I'm guessing I shouldn't use it in my own code) and using the SYS_REBOOT_CTL register (which is what the driverlib SysCtl_A_rebootDevice() call seems to use)
  6. Is the RTOS resilient to a soft reset?  What measures should I take to ensure my code is resilient to a soft reset?  I'm particularly worried that a soft reset leaves a lot of state behind.  As an application starts up it might make assumptions about what the state is (e.g. assumes the POR defaults).  Both RTOS and user code could be vulnerable to associated bugs. 
  7. What is the difference between the following pairs of driverlib calls

ResetCtl_initiateSoftReset() vs ResetCtl_initiateSoftResetWithSource(id)

ResetCtl_initiateHardReset() vs ResetCtl_initiateHardResetWithSource(id)

I've dug into this a little and I see that the first in each pair hits the RSTCTL_REBOOT_REQ register and sets the appropriate bit, which I assume triggers the corresponding sort of reset.  In this case, what will the RSTCTL_[HARD/SOFT]RESET_STAT registers report after the reset? 

The second in each pair above hit the RSTCTL_[HARD/SOFT]RESET_SET registers.  How is this different to the above.  Does this actually trigger a device reset or does it just set the corresponding RSTCTL_[HARD/SOFT]RESET_STAT bit?

Cheers

Julian

  • 0
    TI__Guru 57566 points

    (1) The 16 hardware and 16 software resets found in the datasheet are also referenced in register definitions found in sections 3.3.2 through 3.3.7.  What is not shown in the datasheet is the RSTCTL_RESET_REQ Register in 3.3.1 which shows the explicit(user) control of the hardware and software resets.  Within the context of the Technical Reference Manual, user application control includes the configuration of peripherals(hardware resets) to generate resets in response to an event.

    (2) The reset does not need to be enabled; however, for the hard and soft classes of resets the device needs to be configured accordingly.  So for example the WDT must be enabled and configured to generate a reset on timeout.  Let me know if this is not clear.

    (3) The Reboot reset is a higher class (1) than the hard (2) or soft (1) resets.  The reboot reset is a special class of reset that is initiated only through software control (SLAU356h, page 256, 3.2.2).  The lower class resets do not activate the higher class resets.  As above the resets cannot be disabled, but the device can be configured to prevent the reset source from occurring.

    (4) (TRM, page66, section 1.5.2) “Reset: Reset is invoked on power up or a warm reset. The exception model treats reset as a special form of exception. When reset is asserted, the operation of the processor stops, potentially at any point in an instruction. When reset is deasserted, execution restarts from the address provided by the reset entry in the vector table. Execution restarts as privileged execution in Thread mode.”  I take this to mean that all resets end up at the reset vector.  Not all of them pass through the bootcode.  This is important with regard to the BSL in which boot code checks for certain conditions and jumps to the BSL if those conditions are met.

    (5) SYS_RESET_REQ access is allowed only if SYS_MASTER_UNLOCK register is unlocked.  I believe it is found under SYSCTL_A_Boot.  I agree that you should use SYS_RESET_REQ, I have not had success trying to unlock the SYS_REBOOT_CTL register.

    (6) I assume you mean TIRTOS.  I will need to reach out to the larger team, but I do not believe so.  

    (7)  What is the difference between the following pairs of driverlib calls

        The status registers are not impacted.

        Yes.  A device reset is triggered and the corresponding bits are set in the status register.

    Regards,

    Chris

    EDIT - Fix formating.

  • 0 in reply to Chris Sterzik
    TI__Guru 57566 points
    I was able to confirm that the TIRTOS kernel does not perform any checks or behave differently based upon the reset source. Additional consideration should also be given to how _c_int00 will potentially change (initialize) variables.

    Regards,
    Chris

**Attention** This is a public forum