• State TI Thinks Resolved
  • Locked Locked
  • Replies 6 replies
  • Answers 1 answer
  • Subscribers 30 subscribers
  • Views 7111 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/SM470R1B1M-HT: SM470R1B1M-HT

SM470R1B1M-HT: Unable to reset ARM CPU, unable to halt, using segger JLINK

Vedpp
Prodigy 40 points
Part Number: SM470R1B1M-HT
Other Parts Discussed in Thread: SEGGER

Hello,

I am working with a TI SM470R1B1M based new target board (designed from a previous board that seems to work fine) with IAR embedded workbench & J-Link. I could work with it for a week, but my latest firmware (adding HET for PWM on 8 pins) seems to have put the CPU out of control. Even after power cycle, I cannot debug or erase it.

When I use IAR EWW to debug it, I get error “Failed to halt CPU after reset. Failed to write memory @ 0x00400000”. Image is attached.

The J-Link control panel image is attached.



I tried to use J-Link commander to reset the CPU & halt it, but unable to do so. I tried “r” & “rx 0” commands by setting speed to 8000. The message says “..unable to halt CPU..”, however the “ishalted” command shows “CPU is halted”. I cannot determine CPU is halted or not. If, after this, I try to erase chip from IAR embedded workbench, it still gives error.

I tried checking the clock on OSC IN pin (pin 19), it seems correct (5.224MHZ). The TRST pin (pin 84) shows 2 mS low pulse when ‘r’ command is given on J-Link commander. The TRST pin is not connected to PORRST (pin 68).

The J-Link commander log is attached.

Could you please provide some help to get back control of the CPU.

 

SEGGER J-Link Commander V6.40 (Compiled Oct 26 2018 15:06:29)
DLL version V6.40, compiled Oct 26 2018 15:06:02

Connecting to J-Link via USB...O.K.
Firmware: J-Link V9 compiled Feb 23 2018 11:28:35
Hardware version: V9.10
S/N: 59100659
License(s): GDB
VTref=3.233V


Type "connect" to establish a target connection, '?' for help
J-Link>connect
Please specify device / core. <Default>: SM470R1B1M
Type '?' for selection dialog
Device>sm470r1b1m
Please specify target interface:
  J) JTAG (Default)
TIF>j
Device position in JTAG chain (IRPre,DRPre) <Default>: -1,-1 => Auto-detect
JTAGConf>-1,-1
Specify target interface speed [kHz]. <Default>: 4000 kHz
Speed>8000
Device "SM470R1B1M" selected.


Connecting to target via JTAG
TotalIRLen = 4, IRPrint = 0x01
JTAG chain detection found 1 devices:
 #0 Id: 0x3100E02F, IRLen: 04, ARM7TDMI Core
ARM7 identified.
J-Link>r
Reset delay: 0 ms
Reset type NORMAL: Using RESET pin, halting CPU after Reset

**************************
WARNING: PC of target system has unexpected value of 0xFFFFFFD8 after reset.
**************************

J-Link>ishalted
CPU is not halted.
J-Link>rsettype
Syntax: RSetType <type>

        Types:
        0 = NORMAL (Using RESET pin, halting CPU after Reset)
        1 = BP0 (Using RESET pin, halting CPU with breakpoint @ 0)
        2 = ADI (Software Reset for Analog Devices MCUs)
        3 = NO_RESET (Nothing happens)
        4 = HALT_WP (Using RESET pin, halting CPU after Reset using watchpoint)
        5 = HALT_DBGRQ (Using RESET pin, halting CPU after Reset using DBGRQ)
        6 = SOFT (Software Reset, resetting CPU regs only)
        7 = HALT_DURING (Halt during RESET)
        8 = SAM7 (Software reset for Atmel AT91SAM7 MCUs)
        9 = LPC (Hardware reset for NXP LPC2xxx MCUs)
J-Link>rsettype 1
Reset type BP0: Using RESET pin, halting CPU with breakpoint @ 0
J-Link>r
Reset delay: 0 ms
Reset type BP0: Using RESET pin, halting CPU with breakpoint @ 0
Core does not stop after Reset, setting WP to stop it.
Failed to halt CPU core after Reset (BP@0), using default reset strategy.
Using DBGRQ to halt CPU
Resetting TRST in order to halt CPU
Resetting target using RESET pin
Halting CPU core
Using DBGRQ to halt CPU
Resetting TRST in order to halt CPU
Resetting target using RESET pin
Halting CPU core

****** Error: Unable to halt CPU core
J-Link>ishalted
CPU is halted.
J-Link>mem32 0x400000,1
J-Link>mem32 0x0000,1

****** Error: Read memory error @ address 0x00000000, word access: Memory access
 timeout.
Could not read memory.
J-Link>ishalted
CPU is not halted.
J-Link>rx 0
Reset delay: 0 ms
Reset type BP0: Using RESET pin, halting CPU with breakpoint @ 0
Core does not stop after Reset, setting WP to stop it.
Failed to halt CPU core after Reset (BP@0), using default reset strategy.
Using DBGRQ to halt CPU
Resetting TRST in order to halt CPU
Resetting target using RESET pin
Halting CPU core
Using DBGRQ to halt CPU
Resetting TRST in order to halt CPU
Resetting target using RESET pin
Halting CPU core

****** Error: Unable to halt CPU core
J-Link>

 

 

  • 0
    TI__Guru 62930 points
    Vedprakash,
    I am out of the office until Wednesday the 2nd, and will not be able to look at this closely until then.
    However, it may be helpful to examine your schematic of the R1B1M connections if you could provide it.

    Regards,
    Wade
  • 0 in reply to Wade Vonbergen
    Prodigy 40 points

    Hello Wade,

    Appreciate your quick response, even during holidays!

    I have attached snippets of schematic here, relevant to clock, reset & JTAG. Also, sending you the microcontroller schematic at w a d e v b (at) t i . c o m.

    Thanks,

    Ved

  • 0 in reply to Vedpp
    Prodigy 40 points
    VCCP is tied to 3.3V.

    Ved.
  • 0 in reply to Vedpp
    Prodigy 40 points
    Sorry! I forgot to mention that clock to OSCIN & reset to PORRST is driven by FPGA.

    Ved
  • 0 in reply to Vedpp
    TI__Guru 62930 points
    Ved,
    Happy New Year.

    Thanks for providing schematic and information.
    I do not see anything on the surface that is wrong. However a couple questions.
    1) nTRST connection are not fully shown. nTRST should have pull down of 10K ohm.
    2) Are you properly applying the PORRST and RST reset timing requirements as shown on page 36 of the datasheet?
    3) Is your clock enabled at power up? What is timing of clock relative to PORRST release?
    4) How much jitter is on the clock? Since you are using the PLL, it needs to be able to lock to the incoming reference clock.

    If possible, you can test with PLLDIS pulled high. This will disable the internal PLL and will help isolate if issue is related to clock input.

    Regards,
    Wade
  • 0 in reply to Wade Vonbergen
    TI__Guru 62930 points
    I haven’t heard back from you, I’m assuming you were able to resolve your issue. If not, just post a reply below (or create a new thread if the thread has locked due to time-out)
    Thanks,
    Wade