Struggling a bit with confirming USBDM is operating properly

[briandavidson1]

ERROR

[pgo]

Hi,

Check the 1st tab on the programmer (see attached) for versions.

You can update the firmware using the utility provided (JS16 Bootloader or Firmware Updater) with the current firmware.  (Not on USB3!!)  Some info here:

https://usbdm.sourceforge.io/USBDM_V4.12/USBDM_JS16/html/index.html

It is not surprising that the BDM would be phantom powered from the target.  The  JS16 version uses a very cheap interface chip not intended for any kind of isolation.  The clamp diodes on the I/O may provide a current path.  You get what you pay for   It really depends on the details of how the interface was wired.

It has also unlikely the actual chip specified was used (a particular manufacturer).

You can check the original hardware on:

https://github.com/podonoghue/usbdm-hcs08

https://raw.githubusercontent.com/podonoghue/usbdm-hcs08/master/Hardware/USBDM_SWD_SER_JS16CWJ/USBDM...

The connection to the target would be through the usual 6-pin BDM header - however I note that apparently there is an alternative pin-out used in China? (at least most of the BDMs from there support two different headers.)  I suggest you physically check the wiring as it is easy to damage the BDM pins. See the schematic above for the expected pin-out).  There are only 4 pins required Gnd, Vcc, BGND and RESET.  The last is optional on some chips - I'm too lazy to check CFV1.

You can use the TCL language to interface with the BDM directly.

See UsbdmScript.  '?' will get you a terse command list.  Not really intended to user but you're welcome to play.

USBDMScript incorporating TCL - Copyright(c) 2011
Press ? for help

===============================================================
usbdm_rc.tcl
================
This file is 'sourced' whenever usbdmScript.exe is executed
Add your own custom commands
Type ? for command summary

Typical sequence:
settarget arm
openbdm ;#can add number of reported BDM if needed
connect
regs
===============================================================

UsbdmScript [~] settarget CFV1
USBDM DLL Version = 4.12.1.320
BDM List:
0 - USBDM-JS16-0001 : USBDM HCS08,HCS12,Coldfire-V1 BDM
Found 1 devices
:setTarget CFV1
UsbdmScript [~] openbdm
Opening USBDM-JS16-0001
BDM Version = HW=8D, SW=4C

UsbdmScript [~] connect
:connect
BDM status => Ackn, Speed-sync, Vpp-Off, Vdd-External, RSTO=1, No Reset, CFVx-running
Speed = 4359 kHz (1762 ticks, sync=29.4 us)
Ackn, Speed-sync, Vpp-Off, Vdd-External, RSTO=1, No Reset, CFVx-running
UsbdmScript [~] gs
POWER => Vdd-External
Target status reg => (0x85) = HALT,DONE/MASS,CLKSW, ENBDM,
BDM status => Ackn, Speed-sync, Vpp-Off, Vdd-External, RSTO=1, No Reset, CFVx-running
Speed = 4359 kHz (1762 ticks, sync=29.4 us)
133
UsbdmScript [~]

I tested a JS16 BDM (current F/W and S/W) with a MCF51JE256 using a test image (256K of random data). This was a round-trip test: Program image using programmer, read-back using MemoryDump and verify in the programmer.  This was on Linux.

I have no idea what " target shuts off until power is cycled." actually means.  If you mean the target stops executing and is put in debug mode then that to be expected.  Debug mode may persist over reset as it is useful to debug low-power resets etc.  I forget the details on CFV1.

bye

[briandavidson1]

ERROR

[pgo · Accepted solution]

I'm sorry but most of this is not documented.

To read the XCSR you can use the rs command.

Alternatively rdreg 0x1000+register # will return the raw data from the XCSR/CSR2/CSR3 upper byte value e.g. XCSR = 0x1001

Have a look at the TCL scripts in the installation directory

.../DeviceData/CFV1/ColdfireV1-default-flash-scripts.tcl

You can source those scripts to have less cryptic symbols or write your own routines.

Example script

set CSR 0 ;# - CSR
set XCSR 1 ;# - XCSR
set CSR2 2 ;# - CSR2
set CSR3 3 ;# - CSR3

set ByteRegs 0x1000 ;# Special access to msb
set XCSRb [expr $::ByteRegs+$::XCSR] ;# - XCSR.msb
set CSR2b [expr $::ByteRegs+$::CSR2] ;# - CSR2.msb
set CSR3b [expr $::ByteRegs+$::CSR3] ;# - CSR3.msb

proc opencf {} {

settarget cfv1
openbdm
reset sh
connect
}

opencf
rdreg $XCSRb

bye

[janis_senc]

Senior Contributor V please tell me to program the mc9s08ac128 with usbdm because it keeps giving me trouble

[pgo]

Please post your question as a new thread.

Please provide some details about what you are doing and what the actual problem is.

• Operating system including version
• BDM hardware and software versions.
• What the actual problem is.

Bye

[janis_senc]

Windows 7 32 bit Usbdm 4.12.1.262 I try to program MC9S08AC128 but all the time it throws error trying another MC9S08AW60 everything is ok problem now

[pgo]

Hi,

I cannot really respond to this situation since you are using old version of the software and an OS version I no longer have access to.

You also have not used a new thread, not told me what HARDWARE you are using and have NOT described the problem.

Please do the following to aid in testing:

• Install the latest version from sourceforge (USBDM_4_12_1_320_Win.msi)

• https://sourceforge.net/projects/usbdm/files/Version%204.12.1/Software

• Update the BDM to the current version of the firmware provided with the software

If updating the software has no effect:

• Post an a NEW THREAD so I don't have to look through an unrelated thread to find your post.  This will also allow other people looking for answers to find related rather than random postings.  This is simple courtesy.
• What the problem actually is.  Is there an error message?
• What version of HARDWARE you are using.
• You can try running the debug version of the software which will produce an error log.

• Run the debug version of the programmer usually located in C:\Program Files\pgo\USBDM 4.12.1.320\

You will need to use the command (from the command line in above directory)

.\UsbdmFlashProgrammer-debug.exe -target=hcs12

• Try the failing operation
• Upload the log files located in %APPDATA%\usbdm
  • Flashprogrammer.log
  • usbdm.log

This may provide some information on what is going wrong.

[janis_senc]

greetings, if the forum is a good thing, only if you look at everything so unambiguously, because you can't find much, and you don't understand what you'll get ready, even if you add a file, nowhere does it describe that you can do it with one, and I'll reply soon

[janis_senc]

Windows 7 32 bit Usbdm 4.12.1.262 I try to program MC9S08AC128 but all the time it throws error trying another MC9S08AW60 everything is ok problem now .If MC9S08AC128 you read the flash now problem and write the read everything will be ok, but when you write a new file, what you need is shown, the s19 format recording goes until then, the camera does not respond to the test

[pgo]

PS/ If the image is not propriety you can post it and I can try programming it to a bare chip.

[briandavidson1]

ERROR

[pgo]

Hi,

The Coldfire GDB stub was used with Codesourcery toolchain and there may be some dependencies there.  It was a long time ago at any changes were made to that program.

USBDM supports debugging coldfire with Codewarrior 11 using the GDI debugging interface .  This is a tightly coupled interface rather than a remote connection as GDB uses.  IMHO this is a much better approach.  GDB stubs are a mess to implement with a very inconsistent and bizarre interface that reflects historical evolution from use on full-fledged operating systems that has been hacked to support embedded systems.  The amount of information the stub needs to know about the target is excessive and arbitrary.  Error recovery (when used in Eclipse) is a mess although that may more reflect how Eclipse interacts with GDB rather than being entirely GDB's fault.

Anyway, I have checked that Codewarrior 11.1 still appears to work with a Coldfire target and the USBDM interface using a MCG51JE256.   The USBDM installer adds the plugin to Codewarrior so that the interface is available and installs the GDI DLLs providing Codewarrior is installed (and updated) before USBDM is installed).

I'll have a look at the GDB stub - Can you describe how you are using this with Codewarrior.  Are you actually debugging in Codewarrior or using GDB stand-alone after flashing?

bye