How to reset HCS12 (MC9S12DG128) into Special Single Chip mode using USBDM?

[Mindblaster]

I try to debug a HCS12 chip in field using USBDM. Therefore i wanted to reset the chip into "Special Single Chip" mode to access it using BDM before the first instruction in the Flash is being executed.

For this i now MODA und MODB needs to be low (as in Normal Single Chip mode) but also MODC, which is BKGD must be low on the rising edge of /RESET.

How can i achieve this using the TCL interpreter? I've tried

reset S

but that does not work, chip still comes up in Normal mode.

also

reset S S

gives an errormessage:
% reset s s
:reset 0x08(SOFTWARE, SPECIAL) - Failed
Illegal parameters

Then i tried:

pinSet RST=L
pinSet BKGD=L
pinSet RST=H
% pinSet RST=H
BDM status => Ackn, Speed-sync, Vpp-Off, Vdd-External, RSTO=0, Reset, CFVx-running
:pinSet PIN_RESET_??|

But that does not work.

[Mindblaster]

I did, and the result, traced with an DSO, is always the same:

Regardless which kind of reset-method i choose, the USBDM software always tries to enter special mode, which works in the first but then you see that "small" reset, which must be caused by an internal reset. But how could that be?

[pgo]

Hi,

I have tested with a USBDM_SWD_JS16CWJ and a MC9S12DG128 and it gave the expected results i.e. Reset and BKGD waveforms without the 'extra' reset.  Other tools appear to work correctly e.g. programmer detects the chip correctly and memoryDump is able to read the device.

It has been a long time since I have used a 9S12 so the details are very fuzzy.

I no longer have access to the usual software for these devices (Codewarrior).

I can only offer the following comments:

• The extra reset pulse appears to have invalid levels - it is not pulling down to a low level correctly.  Is there a too low external pull-up or is the reset pin damaged?
• The reset pin on the DG128 is bidirectional so the reset may be from the chip itself but I am unsure what would be the cause.  There are various internal reset sources e.g. COP and Clock Monitor.  I forget the details about whether these are disabled in Special modes.
• Are other devices connected to the reset pin e.g. LV monitor?
• Is the device secured?  I forget the detailed operation when this is true.  Does the chip continue executing and can it then trigger a reset?
• Have you tried auto-detection using the HCS12 programmer?  Does it correctly detect the chip?
• Have you tried reading the chip using the Memory dump program?
• Is the chip blank?
• Why are you using UsbdmScript at all?  It is not intended for manual debugging .  It is used with TCL scripts for handling low level iterface details for the devices e.g. reset sequences and mass-erase.
• What BDM hardware are you using?

PS. Please respond to new posting - not your original - It makes it much easier to follow!

[Mindblaster]

Thank you! This post refer to my first post here https://community.nxp.com/t5/S12-MagniV-Microcontrollers/How-to-access-EEPROM-in-MC9S12DG128/m-p/133... and i maybe should keep that together? Most of your questions are answered there.

I could read out the chip using Xprog and it does not show the extra reset pulse. The Xprog first sets RST and BKGD pin to low, then applies power. My USBDM interface (china clone, made from the schemtics found in usbdm-project on sourceforge/github) has no choice to switch power, it is fixed to 5V of USB.

Maybe, if the chip has bin started before, it is not possible to "warm reset" into special mode?

[pgo]

I'm still a bit confused about what you are trying to do?

What are you trying to do - just read the EEPROM and ROM?

Just use the memory dump program that supports doing both using the PPAGE and EEPAGE registers along with an arbitrary initialisation sequence.

Does it not work?

If you are just using USBDMScript to try out things then the correct connection sequence can be found in the TCL scripts provided with USBDM.

Look in (on linux) - similar location under program files/pgo under windows.

/usr/share/usbdm/DeviceData/HCS12

This includes important things like disabling the COP!

In your previous attempts you haven't used the connect command which enables the debug mode in the BDM register.

Try the following sequence:

settarget HCS12
openbdm
source /usr/share/usbdm/DeviceData/HCS12/HCS12-FTS-flash-scripts.tcl
disableWatchdog
gs

The above connects and disables the COP before it fires? maybe?

bye

[Mindblaster]

Some additional notes

Yes, i have used "connect" but forgott to tell about.

And i also can read from memory.

What's puzzling me is that i can't find an implementation of the BACKGROUND command in the source. How does USBDM enter the debug mode?

[Mindblaster]

My main objective is to learn how BDM works and use it for low-level debugging of existing hardware having failures, so no source-code involved here. And for that i fetched two automotive-control-modules from a rear-view-camera-system out of my box having this processor on the board. Those modules are equal in hardware but different in firmware. What i try to do is to read the whole firmware of one module and program the other with the same.

I think you pointed me to an interesting place, because if i look into that tcl-script, if found absolute defines for severial registers in Register-Space. For example to access the EEPROM-Init register, the file points to 0x0012. But this is only the case if Register-Space is set to 0x0000. In my case i found out that the firmware in the module set the Register-Space address to 0x3000. This is also reflected by the BDM-Register i can read with "rdreg 0xFF07". And so i think USBDM does not respect this shift of RS and looks into RAM instead. Also the COPCTL is not writeable in normal mode, after the firmware has set it once.

It all comes down that the chip is not startet properly into Special mode. As you can see from the DSO capture it takes about 100ms after raising RESET until BKGD comes up also. And a few milliseconds later the internal reset occures. This is not the case when using XPROG, so where is the difference? I thought after bringing the chip into Special Mode, the CPU halts and waits for commands from BDM. And usually no watchdog timer should run here?

It is also interesting that something in the chip could survive a reset. So warm-reset is different from cold-reset when applying power. And this is where i want to get to. I'd like to have USBDM (TCL) driving RST and BKGD to low as default (and not tri-state) and if i apply power the chip is forced to Special mode. Then, if i connect with BDM it should release RST and then BKGD.

[pgo]

Hi,

Out of hardware reset the settings should be at default values.

I confirmed this for the (INITRG) reg.

To do what you are trying to do try something like the following:

proc Connect {} {

;# Apply RST and BKGD
pinSet rst=0 bkgd=0

;# Prompt user to apply power
dialogue "Power cycle needed" "Please cycle target power and click OK to continue" OK|I_Excl

;# Release RST with retry if RST is slow to rise
if { [catch {pinSet rst=3 bkgd=0}] } {
after 1000
pinSet rst=3 bkgd=0
}

;# Release BKGD
pinSet

;# Connect
connect
}

;# Set up BDM
settarget HCS12
openbdm

;# Do POR connect sequence
Connect

;# Status
gs

I do not believe the above is necessary.

bye

[Mindblaster]

Good idea, put this into a file "init.tcl" and execute it and it. It get us a bit further, but the second reset also occures.

% source "C:/Data/BDM/CMR/Dumps/init.tcl"
USBDM DLL Version = 4.12.1.262
BDM List:
 0 - USBDM-JS16-SWD_SER-0001 : USBDM HCS08,HCS12,CFV1,ARM-SWD BDM
Found 1 devices
:setTarget HCS12
Opening USBDM-JS16-SWD_SER-0001
BDM Version = HW=97, SW=4C

BDM status => Wait, No-connection, Vpp-Off, Vdd-External, RSTO=0, Reset, CFVx-running
:pinSet PIN_BKGD_LOW|PIN_RESET_LOW|
BDM status => Wait, No-connection, Vpp-Off, Vdd-External, RSTO=1, Reset, CFVx-running
:pinSet PIN_BKGD_LOW|PIN_RESET_3STATE|
BDM status => Wait, No-connection, Vpp-Off, Vdd-External, RSTO=0, Reset, CFVx-running
:pinSet - all released
:connect
BDM status => Ackn, Speed-sync, Vpp-Off, Vdd-External, RSTO=1, No Reset, CFVx-running
Speed = 4000 kHz (1920 ticks, sync=32.0 us)
POWER          => Vdd-External
Target status reg => (0xC0) = ENBDM, BDACT,
BDM status => Ackn, Speed-sync, Vpp-Off, Vdd-External, RSTO=1, No Reset, CFVx-running
Speed = 3996 kHz (1922 ticks, sync=32.0 us)

I've then modified (simplyfied?) your script a little bit to just contain:

settarget HCS12
openbdm
pinSet rst=0 bkgd=0
dialogue "Power cycle needed" "Please cycle target power and click OK to continue" OK|I_Excl
pinSet rst=3 bkgd=0
pinSet
connect
gs
rw 0x001A 0x1

The result is that it seems the chip go into special mode for a short time and if timing is good (varies), "gs" indicates that BDM is fully enabled and active.and i can read a single address from Register-Space (took Device-ID for test here):

Target status reg => (0xC0) = ENBDM, BDACT,
:rw =>
0x0000001A : 0115

But as you see timing is so tight that most reads will fall after the 2nd reset into normal mode.

[pgo · Accepted solution]

Hi,

There is definitely something wrong with your reset waveform.

The low level reset (other than that from the BDM) is obviously having trouble pulling low.

It appears to be about 2V (not large enough scale to be sure).  This is not a valid low level for HCS12.

This means that either that the device driving reset low has low drive capability or the pull-up is excessively small.

Are there any other devices connected to the reset signal?

It is common to have LVD devices for a HCS12.

Is there an external watchdog?

I have been unable to get my DG128 to misbehave.

PS. Some further testing.

I tried forcing a reset on my chip using the COP to see if this introduces problems connecting.

No issues were found.

Notes:

• The reset pin was fully pulled-down by the internal reset as expected.
• The shortest interval for resets I could get was about 3.5ms.
• reset s h was sufficient to disable the COP resets

% reset s h
:reset 0x04(HARDWARE, SPECIAL)
% gs
POWER => Vdd-External
Target status reg => (0xC0) = ENBDM, BDACT,
BDM status => Ackn, Speed-sync, Vpp-Off, Vdd-External, RSTO=1, No Reset, CFVx-running
Speed = 7983 kHz (962 ticks, sync=16.0 us)
192

bye

[Mindblaster]

Thanks, as you are writing about it i've already found the source of my issues. It was an external watchdog device TPS3820-50DBVRQ1G4 causing the problems. This device expected an pulse at least every 25 ms, or it will create a reset via an 4,7k resistor to the MCU reset-pin. The keep-alive via the WDI-pin of the device came from PB7 of the MCU.

After i removed the resistor, the pulse can't get through to reset of MCU and everything works like a charm now! Even without any special things to do, just settarget, openbdm, connect and reset and go

Thanks a lot for your efforts and excuse me from not seeing this earlier! I was too sticked to the MCU.

% reset
:reset 0x1C(DEFAULT, SPECIAL)
% connect
:connect
BDM status => Ackn, Speed-sync, Vpp-Off, Vdd-External, RSTO=1, Reset, CFVx-running
Speed = 4000 kHz (1920 ticks, sync=32.0 us)
Ackn, Speed-sync, Vpp-Off, Vdd-External, RSTO=1, Reset, CFVx-running
% regs
regs
 PC =4A4D,   D =   0,   X =   0,   Y =   0,  SP =   0,
PC = 0x4A4D : 0x80E6 0x801B
% rb 0x0000 0x100
:rb =>
  0x00000000 : 00 40 00 00 00 00 00 00 0B 00 00 00 90 00 01 00
  0x00000010 : 09 00 01 0D 00 0F 00 10 00 00 01 15 13 80 40 F2
  0x00000020 : 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x00000030 : 00 00 BF 00 00 00 00 5C 00 00 F1 00 00 00 80 00
  0x00000040 : 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x00000050 : 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x00000060 : 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x00000070 : 00 00 00 00 00 00 FF FF 00 00 00 00 00 00 00 00
  0x00000080 : 00 00 00 20 05 00 00 00 80 00 00 00 00 00 00 FF
  0x00000090 : 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x000000A0 : 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x000000B0 : 00 00 00 00 FF FF FF FF FF FF FF FF FF FF FF FF
  0x000000C0 : FF FF FF FF 00 00 00 00 00 04 00 00 C0 00 00 00
  0x000000D0 : 00 04 00 00 C0 00 00 00 04 00 00 20 00 00 00 00
  0x000000E0 : 00 00 00 80 00 00 00 00 C0 00 40 00 47 00 00 00
  0x000000F0 : 04 00 00 20 00 00 00 00 00 00 00 00 00 00 00 00
0

[pgo]

Try reset S H

S = special, H= hardware = reset pin

Type ? for help and read below:

reset <N|S><H|S|P|V|A> - Reset (N=normal,S=Special), (H=Hardware,S=Software,P=Power,V=Vendor,A=All

It is a good idea to check the connection with the HCS12 programmer first (if not done already)

If using the direct pin manipulation I think you need 3 = 3-state rather than h=high since reset doesn't actually drive.

See:

pinSet <pin=level> - Control pins, pin=RST|BKGD|TRST|BKPT|TA|SWD, level=H|L|3|-