USB BDM pods?

[khumphri]

This message contains an entire topic ported from a separate forum. The original message and all replies are in this single message. We have seeded this new forum with selected information that we expect will be of value to you as you search for answers to your questions.

Posted: Fri Oct 28, 2005  10:50 pm

I'd like a USB based BDM pod for 9S12 devices.

I am looking at the SofTec users manual for their 9S12XDP256 eval board. The board contains an on board BDM to USB converter, which just happens to be based on an MC9S12UF32 microcontroller, which is USB based. I suspect this pod uses a modified DBUG-12 syntax.

For those that aren't aware, these pods typically run the DBUG-12 Freescale firmware. One can build their own DBUG12 pod by taking a 9S12 device and adding a cable between it and the target device. Not that I am advocating that.

So... does anyone know of a USB based DBUG-12 pod or where one can obtain the firmware for a USB based pod ?

Thanks.

---

Date: Sat Oct 29, 2005  1:02 am

Have a look at the TBDML BDM device in the Community Files section of this community (see left nav under 16-Bit Microcontroller Community).

Regards,

---

Date: Sat Oct 29, 2005  2:15 am

Thanks. That is basically what I am looking for and I love the fact it is open source. However, it has a speed limitation and probably won't work with a 40MHz 9S12X. I'm taking a closer look at it.

Has anyone modded gdb for the tbml ?

---

Date: Sat Oct 29, 2005  3:26 am

> I'd like a USB based BDM pod for 9S12 devices.

We (Bendor Research) are at the last stages of the development of a universal USB pod. It can handle quite fast target bitstream speeds (with the HC12's one wire debug it can cope with CPUs running up to ~80MHz clock), practically any protocol (it is user programmable down to the lowest delay specification level), including hc12, 683xx, PPC8xx and non-Freescale chips as well, but you can use it to do JTAG or CAN or whatever else, as long as your target has some serial bitstream to generate or monitor (up to 4 serial streams, 2 independent clocks and a handful of control signals can be handled simultaneously). The actual bottleneck is the 1.1USB (12Mb/s) we use, but you have quite a lot of buffer space to compensate for that.

We plan to release it early next year, so you might want to check out our website (www.bendor.com.au) sometime in January for this, if you will still be interested. We will probably put up all the prelim docs on the site in mid-December.

---

Date: Sat Oct 29, 2005  3:46 am

> We plan to release it early next year, so you might want to check out our website

> (www.bendor.com.au) sometime in January for this

Will there be any kind of standard DLL for accessing the BDM functions via the USB interface? If so, will the API be made public?

One of the things that bugs me about Segger is that they charge a couple hundred dollars for the SDK to enable the use of their DLL interface to their j-link USB JTAG device for the ARM.

If there's an open standard for the API, its much more likely that your device will be supported in IDEs, and that would be good for your bottom line!

Also, we don't want to forget about linux users. My unscientific study of web site hits indicates about 20% of users with an interest in the hc12 are using some flavor of linux. This is much higher than I expected. I'm going to see about porting some of my code to linux over the next year...

---

Date: Sat Oct 29, 2005  6:06 am

> Will there be any kind of standard DLL for accessing the BDM functions

> via the USB interface? If so, will the API be made public?

The entire interface set will be public, together with everything you have to know about the programming of the device, interface it with whatever target you have and whatever op.sys., debugger or special SW is on the end of the USB.

We want to sell the *device* and actually we plan to rely on the user community to make it more capable by writings programs for it and share the code with other users. We have neither the capacity nor the inclination to develop secret interfaces for all conceivable target, op.sys. and debugger combinations. Rather, we try to sell a box that the users can turn to be the intelligent middleware for any such combination. We will see if it is sound business tactics or not.

> One of the things that bugs me about Segger is that they charge a couple

> hundred dollars for the SDK to enable the use of their DLL interface to their

> j-link USB JTAG device for the ARM.

We sell you the pod and we tell you everything about it that you may need to know to use it for practically any purpose. In that regards we see ourselves as HW manufacturers and openness is what gives us access to the widest possible customer base. All docs will be available on our website, even before we actually start selling the device.

> Also, we don't want to forget about linux users. My unscientific study of web

> site hits indicates about 20% of users with an interest in the hc12 are using

> some flavor of linux. This is much higher than I expected. I'm going to see

> about porting some of my code to linux over the next year...

Every computer we have is running Linux (well, we have a decommissioned SparcClassic with Solaris on it). So Linux users are kind of close to us

---

Date: Sat Oct 29, 2005  3:41 pm

> > Will there be any kind of standard DLL for accessing the BDM functions

> > via the USB interface? If so, will the API be made public?

>

> The entire interface set will be public, together with everything you

> have to know about the programming of the device, interface it with

> whatever target you have and whatever op.sys., debugger or special

> SW is on the end of the USB.

Great news! My open source debugger will be out in the December/January timeframe and I'd love to look into supporting this USB BDM device!

My initial release will only support the serial monitor, but I will add support for d-bug12 after that.

A USB BDM would be a nice option for users who need more functionality than what is supported by the serial monitor and d-bug12.

---

Date: Sat Oct 29, 2005  4:04 pm

> Great news! My open source debugger will be out in the December/January

> timeframe and I'd love to look into supporting this USB BDM device!

Tell us more about your open source debugger. What was wrong with gdb?

Does your debugger work with elf/gcc source?

> My initial release will only support the serial monitor, but I will

> add support for d-bug12 after that.

I wrote a stub for gdb that supports d-dbug12. d-bug12 was NEVER designed to interface to a debugger program. d-bug12 was designed to BE a debugger program, although not a very good one, nor one that could support C source level debugging. (At this point I am scratching my head as to why Freescale built it as such given how much they tout C as the programming language for the 9S12 stuff.) I guess something is better than nothing.

> A USB BDM would be a nice option for users who need more functionality

> than what is supported by the serial monitor and d-bug12.

I looked at this long and hard over the last few days and I've come to the conclusion that the BDM pod should only support the BDM primitives and leave the higher level functionality to the debugger program. If the BDM pod implements anything more than the primitive BDM functionality then it limits what the debugger can do with the target.

So, for the 9S12X, the BDM would need to implement the following:

(from Chapter 18 in the 9S12XDP512 manual)

HW Commands

- Background

- Enable and Disable Ack

- Read and write BD_Byte

- Read and write BD_Word

- Read and write byte

- Read and write word

- I think the pod will need to send an "Ack received" or "Timed out" message to the debugger.

Firmware Commands

Read and Write: Next, PC, D, X, Y, SP

Go, Go_Until, Trace.

That is all I want the BDM Pod to do. Nothing more. I can handle all the rest of the debugging chores from the debugger software, where I want to handle them. This will be especially true when one starts building debuggers that handle XGATE debugging on the 9S12X devices.

It might have been advantageous to do more when the BDM pod was connected to the debugger via a slow serial cable, but with a properly tuned, speedy USB cable, I want the debugger as close to the hardware as possible and that means a primitive BDM pod.

---

Date: Sun Oct 30, 2005  1:38 am

snip...

> It might have been advantageous to do more when the BDM pod was connected

> to the debugger via a slow serial cable, but with a properly tuned, speedy USB

> cable, I want the debugger as close to the hardware as possible and that means

> a primitive BDM pod.

USB full speed is not all that much faster then serial at best, and slower in many small packet protocols, USB 2 might be a much better choice long term. As USB sends packets every 1 millisecond only, if you only send a few bytes each time then the old serial port can be faster.

Regards,

---

Date: Mon Oct 31, 2005  1:31 am

> snip...

>

> > It might have been advantageous to do more when the BDM pod was

> > connected to the debugger via a slow serial cable, but with a properly

> > tuned, speedy USB cable, I want the debugger as close to the

> > hardware as possible and that means a primitive BDM pod.

>

> USB full speed is not all that much faster then serial at best, and slower in many

> small packet protocols, USB 2 might be a much better choice long term. As

> USB sends packets every 1 millisecond only, if you only send a few bytes

> each time then the old serial port can be faster.

Are you intimately familiar with USB protocols ? There are 4 different types of data transmission (control interrupt,isochronous and bulk). I haven't tested this yet, but I am betting that I can make USB 2.0 work better than serial.

There is more to this story... the real issue is programming devices with a laptop that doesn't have a serial port, as is all too common these days. I am working with devices in the field and setting up a desktop with a serial port isn't an option. Right now I am using a USB<->Serial adapter connecting to D-bug12 BDM pods. The issue is I am downloading significant quantities of code and having to do it slowly because D-Bug12 doesn't support hardware handshaking and XON-XOFF works terrible with the USB<->Serial adapters.