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

Original question:

CCS/TMS570LS3137: Tracking PORST occurrence by SYSESR

CCS/TMS570LS3137: Tracking PORST occurrence by SYSESR

_MM_
Expert 1995 points
Part Number: TMS570LS3137
Other Parts Discussed in Thread: HALCOGEN

Tool/software: Code Composer Studio

I do not understand what would be the value added when I have the MCU with a blank flash: I would like to track resets when the MCU is working with a SW running inside it.

  • 0
    TI__Mastermind 49120 points
    Marco,

    I am missing a question in your post. May be the complete post was not uploaded?

    When a power-on-reset condition is detected and indicated via SYSESR, you can ignore all the other reset conditions indicated in the SYSESR (EXT RST will also be set). You can use this condition to clear all the flags in the SYSESR so that if an actual system reset occurs the next time, you can identify the correct cause for the reset in the reset handler (c_int00).

    Regards,
    Sunil
  • 0 in reply to Sunil Oak
    Expert 1995 points
    Yes, I am seeing that the original post was not shown. Please, follow the link below:
    e2e.ti.com/.../699838
  • 0 in reply to _MM_
    TI__Mastermind 49120 points
    Marco,

    The flash does not have to be blank. The SYSESR register is not auto-cleared on a reset. It contains status flags that indicate the cause of any reset. The application code running in the MCU (reset handler) reads these status flags and takes the appropriate response. For example, a reset caused by an oscillator fault could require a specific response from the application.

    The application's response to each reset condition is up to the application. HALCoGen only provides a way to sort through the SYSESR register to identify which reset condition occurred. You can have your own reset handler that does not clear the PORST bit in SYSESR. Then you should be able to see this bit set on each power-up.

    Regards,
    Sunil
  • 0 in reply to Sunil Oak
    Expert 1995 points

    I put a checkpoint during debug right before the power-on reset is checked; I reset manually the SysEsr and pressed PORRST. My expectation is finding the PORST bit of the SysEsr to 1, but when I reconnect to the target, the console displays the following message and the program hangs at "abort" (and the PORST bit is not 1 anyway):

    Before PORRST:

    CortexR4: GEL Output: 	Memory Map Setup for Flash @ Address 0x0CortexR4: GEL Output: 	Memory Map Setup for Flash @ Address 0x0 due to System Reset
CortexR4: GEL Output: 	Memory Map Setup for Flash @ Address 0x0 due to System Reset
Dap: Error: (Error -242 @ 0x0) A router subpath could not be accessed. The board configuration file is probably incorrect. (Emulation package 6.0.576.0) 
CortexR4: Error: (Error -2063 @ 0x0) Unable to reset device. Power-cycle the board. If error persists, confirm configuration and/or try more reliable JTAG settings (e.g. lower TCLK). (Emulation package 6.0.576.0) 
CortexR4: Error: (Error -1170 @ 0x0) Unable to access the DAP. Reset the device, and retry the operation. If error persists, confirm configuration, power-cycle the board, and/or try more reliable JTAG settings (e.g. lower TCLK). (Emulation package 6.0.576.0) 
CortexR4: Unable to determine target status after 20 attempts
CortexR4: Failed to remove the debug state from the target before disconnecting.  There may still be breakpoint op-codes embedded in program memory.  It is recommended that you reset the emulator before you connect and reload your program before you continue debugging
CortexR4: Read timer value failed.

    After PORRST:

    CortexR4: GEL Output: 	Memory Map Setup for Flash @ Address 0x0CortexR4: Error enabling this function: There is no AET resource to support this job.
CortexR4: Error enabling this function: There is no AET resource to support this job.

  • 0 in reply to _MM_
    TI__Mastermind 49120 points
    Hi Marco,

    Asserting power-on-reset also resets the debug sub-system so that the connection to the debugger is lost (as you observed). The best way to check for the PORST bit to be set on a power-on-reset condition would be to do the detection in software. The reset handler could read the SYSESR for the bit 15 to be set, and then drive a device pin, say ECLK (or any other unused I/O pin), high.

    Regards,
    Sunil
  • 0 in reply to Sunil Oak
    Expert 1995 points

    Can the power-on reset be made only by removing physically the power supply (without touching the debug probe), or there is some register corresponding to the PORRST pin that can be switched on ?