m68332 BDM and …. gdb ???

[legacy]

hi guys
i am toying with a tiny mc68332 board which has BDM interface
and i guess if there is a working debug interface for gdb or … anything else around

let me know

[andersm]

Have a look at the BDM tools package. Never used it myself.

[legacy]

yeah, but it seems old, and i'd like to have feedback about 

also, anybody toying with gdb-stub for m68k ?

[westfw]

it seems old

The 68332 is an OLD chip...
Likewise, you shouldn't have any trouble finding a gdb stub for 68k.  It WAS one of the first CPUs suppored by gdb.   IIRC, the 68k gdb_stub most people use was written at HP, back when they were selling 68k workstations.  (Hmm.  The one I found looks like it would need some editing before it will compile with a modern version of gcc.  Strings (asm) with embedded newlines have been deprecated for a long time.)

[legacy]

BDM is stills used by freescale, unfortunately they have and sell closed and expensive debuggers and Applications
and about easier and cheaper ones  .. it seems there is no one using gdb with it.
I have found an old (2003) project that aims for that, but .. no feedback from his author

[nctnico]

A couple of years ago some Freescale rep. tried to push their 68k based microcontrollers. After finding out there are no easy/cheap tools for 'flashing' those I quickly send the demo board back for a refund.

[legacy]

i simply like m68k, especially m68332, i have recently realized two tiny boards and i'd like to put a debugger on. I am currently using dbug32, which is able to upload srec and .. may be it can used with gdb, too. btw, i'd like to have a debug interface to the BDM.

[legacy]

after finding out there are no easy/cheap tools for 'flashing' those

Motorola has released a free tool package which contains BDM-LPT schematic to make you able to realize a low cost BDM cable, and a DOS program that drives such a cable

the whole is able to flash a binary to the flash simply attaching the BDM cable on a running system, that means … i was able to put my old DOS laptop back to the present and use it to put dbug32 on the flash chip i have soldered on my two tiny boards

i mean: i have soldered everything on these boards, and i have soldered an empty flash on them, then i connect the BDM cable and i flashed them throughout the motorola BDM software, which is free


My problems are:
1) such an interface is DOS only, and i can't run DOS on my modern systems
2) such an interface is using the LPT port, and i do not have any LPT port on my modern systems (only USB, ethernet, eSata)
3) such an interface has no debug implementation support, it is only able to flash things

[legacy]

you are right for those who want professional tools and don't want to spend $500 USD for a P&E USB BDM 

[nctnico]

Well compare $500 to the $5 USB to serial converters I use to load software in the NXP controllers I use. You have to sell a lot of units to make up for the difference IF the controllers from Freescale are actually cheaper. You may think that a business comes with a tree with free money but the reality is that you have to think about every penny you spend. Return on investment is the key word here. In my case the $500 is not worth spending just to use the M68k controllers from Freescale.

[legacy]

Well compare $500 to the $5 USB to serial converters I use to load software in the NXP controllers I use.

it seems to me like comparing an home made extremely cheap (and limited) download cable with the professional one 


edit:
btw, i am looking for a good BDM, i am not interested about these considerations.

edit2:
see this bdm ICE for hc12, it's very impressive, also the sw interface is cool

[legacy]

i have found this project, OpenSource BDM Interface

[legacy]

and https://github.com/osfreedom/bdm-osbdm this other bdm-osbdm project

[andersm]

For hardware interfaces, there's USBDM and PE Micro's OSBDM, but I don't think either supports CPU32.

[westfw]

None of the CPU32 chips have any flash, do they?
Coldfire had a $99 bdm adapter...

[legacy]

None of the CPU32 chips have any flash, do they?

nope, no flash, and i like they do not have flash inside the CPU package!
i have designed a pair of MRam chips on my two tiny boards, and i am very happy about that.

about BDM … which cable are you talking about, and which software is driving such a cable ?

[westfw]

which cable are you talking about, and which software is driving such a cable ?

https://www.freescale.com/webapp/sps/site/prod_summary.jsp?code=USBMULTILINKBDM

I haven't actually used it, and I see it's actually from PE-micro rather than direct from motorola...
(there is also: http://www.pemicro.com/products/product_viewDetails.cfm?product_id=15320137 )

Huh.  Freescale made a pretty big deal about making the BDM "open", and about OSBDM.  It seems strange that there aren't more "hobbyist level" tools around...

[snoopy]

A couple of years ago some Freescale rep. tried to push their 68k based microcontrollers. After finding out there are no easy/cheap tools for 'flashing' those I quickly send the demo board back for a refund.

That is the typical motorola business model. Sell you a chip and expect you to pay 3rd parties megabucks for software support. What a racket that was and it's good to see that other chip vendors never followed this ridiculous and elitist model

I remember a place I worked at years ago payed out $40,000 for a German made ICE just to debug code for a 68000 based product. I argued with them at the time to go down the x86 route but they wouldn't listen to me

My advice to anyone is don't use motorola 68K stuff. The architecture was good in its heyday but is ancient by comparison now.

cheers

[legacy]

The architecture was good in its heyday but is ancient by comparison now.

i think the m68K ISA is still the most elegant and easy one
ARM is complex, MIPS is much more complex at the assembly level
especially if you have to deal with pipeline approach!

btw, i have already built 2 tiny boards with 68332 on them, it's for hobby purpose
so in my choice i could not use the BDM, i could use a gdb-stub instead, but …
… i'd like to see if i can use the BDM because  have its tap inside chips,
so why don't to make it a chance ?

[snoopy]

The architecture was good in its heyday but is ancient by comparison now.

i think the m68K ISA is still the most elegant and easy one
ARM is complex, MIPS is much more complex at the assembly level
especially if you have to deal with pipeline approach!

btw, i have already built 2 tiny boards with 68332 on them, it's for hobby purpose
so in my choice i could not use the BDM, i could use a gdb-stub instead, but …
… i'd like to see if i can use the BDM because  have its tap inside chips,
so why don't to make it a chance ?

No one bothers with assembler these days because the C/C++ compilers of today do such a good job at optimizing the code.

We had all of those BDM pods etc for the 68340's etc and none of them worked properly. We even had this debugging kernel which was supposed to work over a serial port. It never worked properly either especially when you were debugging an RTOS. I'm glad that motorola became obsolete. They needed to be shown the door.

cheers

[bwat]

I remember a place I worked at years ago payed out $40,000 for a German made ICE just to debug code for a 68000 based product.

Lauterbach?

[westfw]

Geeze...  We debugged our 68k products (68000, 68020, 68ec030, 68331, 68302, probably more...) with a "rom monitor" (one breakpoint, deposit/examine/etc commands) and (later) a gdb stub over a serial line.  And the occasional oscilloscope...

[snoopy]

I remember a place I worked at years ago payed out $40,000 for a German made ICE just to debug code for a 68000 based product.

Lauterbach?

yep you guessed it And they are still in business today !!

[snoopy]

Geeze...  We debugged our 68k products (68000, 68020, 68ec030, 68331, 68302, probably more...) with a "rom monitor" (one breakpoint, deposit/examine/etc commands) and (later) a gdb stub over a serial line.  And the occasional oscilloscope...

It wasn't my idea to spend that ridiculous amount of money just to debug some code on a 68K. I told them to ditch the 68K and go for the PC in an industrial case. At the same time I was working on other projects which used a PC motherboard running MSDOS in a flash based disk emulator. It was easy to develop and debug code using Visual C++ or Turbo C even under DOS. Numega Soft ICE gave me ICE like functionality using the 386 debug registers etc if I needed it.

Every joint I worked at that used 68K stuff had the same problem of having inadequate tools to debug their code simply because they didn't want to spend 30K or more to do it.

cheers

[legacy]

Geeze...  We debugged our 68k products  with a "rom monitor" (one breakpoint, deposit/examine/etc commands) and (later) a gdb stub over a serial line.  And the occasional oscilloscope...

i have put dbug32, such a rom monitor, inside the main flash of my tiny boards, it should be compatible with gdb-server as it is working as gdb-stub.
I am using dbug32 to upload things through the serial line in S19 format, also i have used the BDM interface to put dbug32 into the flash (on board flash programming through debug interface, something like programming a flash through a jtag)

i have realized also a big board with a 68060 on it, and in this case …. i have no BDM, but the 68060 should have a jtag port, i got its BSDL file from Motorola (opening a free customer care ticket) and it may be i could ever use it.

i am just looking for the best way to do debug

[nctnico]

By far the best way to debug is to write&test code on a PC first. Avoid debugging software running in an embedded platform as much as possible because it is very time consuming.

[legacy]

No one bothers with assembler these days because the C/C++ compilers of today do such a good job at optimizing the code.

nope, it depends by your compiler

[legacy]

By far the best way to debug is to write&test code on a PC first. Avoid debugging software running in an embedded platform as much as possible because it is very time consuming.

yeah, that's true, i am used to develop on my host pc and then migrate everything to the target, that is keep development time shorter, and it is OK except when my issues go around hw issues, such as driver and interfaces, which are target dependent and can't be handled on PC. Well, i could think about "virtual CPU" simulation, especially with my fpga SoC (mips1 compliant), this way i could use GHDL plus pseudo term and other supporting stuff to simulate the whole SoC on PC, also i could inspect the RTL level with gtk-wave, and i can also try to reproduce devices behavior and response with test bench … but … it is the same a great time consuming job and i can't be sure that it is simulating exactly what it is happening on the real hardware, especially with asynchronous event.

[nctnico]

The first rule of using gcc+binutils is to use a precompiled package (from Linux for example) or compile a known good combination combination of sources. Putting a compatible gcc+libc+binutiles+etc together by yourself is a nightmare indeed and shouldn't be attempted.

[snoopy]

No one bothers with assembler these days because the C/C++ compilers of today do such a good job at optimizing the code.

nope, it depends by your compiler

Sierra C for m68k (it is a old dos product, used by Texas Instruments in their m68k pocket calculator, i got a copy of such a compiler because it was used in m680X0 IDP board as evaluate system by Motorola, i got a 5.1/4 floppy disk with it inside, i asked the Motorola customer care to get a copy of this  in order to put it into my linux/dosbox emulator, and they sent me a Zip file) is the most beautiful C compiler i have ever tried, it does excellent job with very optimized code that is still readable by humans, while gcc-m68k is simply a shit (also GAS, the GNU ASssembler, is incompatible with itself, you can't compile old gnu-m68k assembly with modern m68k gas because they have changed things just in order to make you frustrated)

the same happens with MIPS-PRO for SGI/Irix (i got it, i own an SGI workstation plus a full IRIX work set), it does an excellent job for both 32 and 64 bit of MIPS4, such as R10000, R12000, R14000, R16000, also it can be targeted to MIPS3, such as R4000, R5000, or MIPS1, such as R3000 (this is used, today, for fpga Softcore). The code is very well optimized, it could be optimized with custom rules (such has NO delay-slot, add hazard detect, do not add hazard detect, do not use stack, force the use of register instead of stack, etc etc, everything easy and well documented without the confusion of GNU)  and still readable while gcc-mips is an other shit.

my conclusion: to trust the compiler you need a good compiler, sierra and MIPS-PRO are not OpenSource products, as Cosmic-m68k (an other excellent C Compiler), and so on, so in my opinion … if you want to trust the compiler .. you'd better forget to use the GNU-shit, that means …. spending money, a lot of money on toolchains.

I do not like GNU, i hate their mind complexity for everything and i hate compiling their gcc/binutils (which i did to a lot of target, i cross compiled gcc for PowerPC, MIPS, m68k, arm, HPPA2, and 68hc11, too) because it is always a slaughter (gcc is itself written as shit, and it can go incompatible with itself, that means gcc can't occasionally recompile gcc, it happens especially with m68k), i HATE gcc very deeply, i am seriously thinking about migrate to LLVM instead, but as the fact LLVM is still a too young product … i am using GCC just because other compiler are no compatible with my hobby's budget (especially if i have to share my sources with others, i can't pretend others can buy an SGI workstation to compile MIPS sources with MIPS-PRO, for example)

also, for my hobby purposes (and in order to keep the gcc-shit away from my eyes) i simply like toying with assembly sources like old fashion days of a lot of years ago

that's all

All of this stuff should be in a museum IMHO. You shouldn't be writing code for it in this day and age.

But having said that this dude resurrected the old Microbee computer and used a Coldfire micro on it. Maybe he can help you

http://www.microbeetechnology.com.au/retro_computing.htm

cheers

[legacy]

All of this stuff should be in a museum

that's true

[legacy]

and years later it's still an unsolved problem 

[westfw]

and years later it's still an unsolved problem

I thought your last messages looked like you HAD solved the problem...  I guess I'm missing the big picture of what you're trying to do, other than "develop for arbitrary obsolete target systems on arbitrary obscure desktop development environments." :-(

you should've spent your time working on an Arduino modular debug/program module.gdbstub, stk500, osbdm, CMSIS/DAP modules on the uplink side and BDM, SWD, JTAG, debugWire, UPD, on the downlink side.Digging up an old DOS laptop with a parallel port is all very fine and good, but sometimes it's easier to start from scratch.
(I guess these "standard debug interface" microcontrollers tend to have a problem in that they don't actually know how to write to flash.  Instead you have to have target-specific code that either is loaded into RAM of the target and knows how to program flash, or you have to indlvidually manipulate the flash memory controller registers over the debug interface.  "Just load a program" becomes one of the hardest things to do.)

[joeqsmith]

There's an old relic.  I still have an ICE for it.   The BDM was pretty powerful.  I wrote my own software for it and used that to bring the hardware up. 

[legacy]

I thought your last messages looked like you HAD solved the problem... 

partially solved, but it's not a 100% working solution, and I am not 100% satisfied.

you should've spent your time working on an Arduino modular debug/program module.gdbstub, stk500, osbdm, CMSIS/DAP modules on the uplink side and BDM, SWD, JTAG, debugWire, UPD, on the downlink side.

I don't like Arduino, Avr8, and that stuff.

[legacy]

There's an old relic.

The 332 is still used in spectrometers and in a couple of Ford Racing's combustions engines.
I am specifically interested in both of them.

I still have an ICE for it.

which one? with which software?

The BDM was pretty powerful.  I wrote my own software for it and used that to bring the hardware up.

Does it mean that you have the full documentation of the BDM timing for CPU32?
The BDM used in Coldfire is not exactly the same as the one used for CPU32.

[legacy]

today, after 2 days of fighting against gcc and GNU things, I have compiled an old gdb-m68k with the BDM support enabled. The funny news is related to the kernel driver, in the actual solution the BDM-driver uses the so pretty old LPT printer port which modern PCs are missing, fortunately, I haven't trashed/sold-out on ebay my pretty old laptop P3

this is what I wrote, that means

• able to upload code and data via the BDM, using the LPT-cable. It works, but ... updating programs is slower than using the ROM-emulator I built
• able to do a minimal debug via gdb, but it's not exactly reliable, sometimes it freezes and I a lot of features are not implemented. Hence I am using a software gdb-stub on the serial line

After this post, I bought an EVS board, that comes with a BDM-debugger integrated into a module that talks serially to a DOS program. It comes with the full debugging support for Sierra C, including useful features like the possibility to set hw-breakpoints!

It's slow since it talks at 19200bps, but you can have a decent debugger. I happen to have had a couple job experiences with Lauterbach's ICEs for CPU32: no doubt, it is by several light-years ahead from the EVS which is, at least, better than the BDM-cable handled by a partially working gdb-bdm resurrected Linux driver.

We have made progress.

Unfortunately, the serial protocol is not documented (already asked to Motorola-Freescale). What I am doing now is reversing the serial protocol, hence I would be able to develop a specific gdb-bridge.

[joeqsmith]

There's an old relic.

The 332 is still used in spectrometers and in a couple of Ford Racing's combustions engines.
I am specifically interested in both of them.

I still have an ICE for it.

which one? with which software?

ICE is a Microtek.     

The BDM was pretty powerful.  I wrote my own software for it and used that to bring the hardware up.

Does it mean that you have the full documentation of the BDM timing for CPU32?
The BDM used in Coldfire is not exactly the same as the one used for CPU32.

I have the CPU32 manuals.  I'm not sure what the "full documentation"  would refer to.  That's going back about 20 years but don't remember the BDM being too complex.  I was using it to test the hardware then load the FLASH and run some basic system checks.   It worked very well for testing out new hardware. 
 
Your title states m68332, so I had assumed this is what you were asking about.  I don't have anything for the Coldfire but it's new enough that you shouldn't have any problems finding information on it.   

[legacy]

I have the CPU32 manuals.  I'm not sure what the "full documentation"  would refer to. 

CPU32 manuals don't talk about the BDM at the timing level. This information is reserved, but I need this low-level information to create my own BDM interface with an FPGA.

anyway, which software did you use on your Microtek?

[legacy]

Lauterbach?

I am evaluating this possibility.

[legacy]

oh, I had forgotten there was also this topic, talking about the EVS board (EVS, BBC-DI module).

It was 2015, in the meanwhile I suspended that project and fully complete the debugger Otaku-v3 unit of my softcore Arise-v2, whose constraints and protocol are of my own design.

That means: designing something completely new from the scratch takes less time than trying to reverse something, mainly because in this case you waste time at finding information and trying to figure out other people's choices and decisions 

Anyway, now I am able to fully run the DI protocol on the EVS board by using a DOS laptop 


edit:
and this topic was about BDM&C

[joeqsmith]

Yes, that in that old thread I had covered it all before.  Nothing's changed since then on my end.

The Microtek came with software called "Powerviews" and "PowerPack".  That HP one I showed has software built into it.  I think that one is actually based around the MC68331.    I used both the MRI and Crosscode tools with them.  I had another debugger that worked with the lower cost P&E interface  I showed you but it was never stable enough to actually use.  I think it was from SDS but again, that's been a very long time ago.

If you really are interested in getting an ICE, eBay has a few:
https://www.ebay.com/itm/Microtek-PowerPack-with-68360-CPU32-probe/302598272613?hash=item4674433665:g:5ZAAAOSwPkBaVs3Y

https://www.ebay.com/itm/vintage-EST-SERIES-300-Background-Debugging-System-CPU32-BDM-Port-Manual-J-4/201316508159?hash=item2edf6621ff:g:PE0AAOSwv0tVEwpC

[legacy]

Looking at eBay. The first dude is not willing to ship to Italy, the second dude doesn't have the CPU probe and doesn't know the status of the equipment is offering.

I'd prefer to acquire an equipment that
- is complete with all the necessary parts
- is in a known working status
- is provided with all the necessary software and documentation to make it runs.

everything else is a gamble

[westfw]

My CPU32 manual has a 35-page chapter on BDM details.  Is this what you have, or would it be useful?

[legacy]

or would it be useful?

Useful, but some information is missing there.

[legacy]

So, I am a lucky man, I have recently met a dude who works on a company affiliated to Motorola/Freescale/..., and he has all the timing documentation about the BDM for CPU32.

He can't share the physical documentation (there must be legal reasons here), but he can give me hints and help. I see ... a solution 

[westfw]

[35 pages of BDM docs]  Useful, but some information is missing there.

Wait - I could swear the last time I looked at your reply, it said that you had "all the manuals" so this was irrelevant?I have the 1989 CPU32 manual, which has 35 pages of BDM info, including a couple timing diagrams, some logic schematics, and a bunch of block and state diagrams.  Do you want me to scan those for you or not?
I've also got a dust-covered 68332 eval board of similar vintage (for which I have neither manuals nor development-side software for, as far as I know.)We used it for pre-hardware-availabilty bringup of the cisco-500cs Terminal Server (which used a 68331.)  While I did some of the "managerial level specification" ("oh!  It looks like this 68331 chip would work really well!") for that box, the actual hardware design was done by an outside vendor, and the firmware bring-up was done by a guy I had working for me.  I don't think we used the BDM capabilities much, or at all; by that time we had a pretty pat method of getting the code running on new 68k variants, and used mostly a serial-based gdb stub for the higher-level debugging.
(I've still got some cisco-500cs terminal servers, too.  I wonder if there is any BDM access on the board?)(this was also the platform that got royally screwed by Intel's Flash debacle.  It was supposed to get a flash-memory card added on after FCS, but Intel's Flash from production-level Fabs turned out to not actually work, leading to a several-year period where flash was severely rationed and expensive.  The 500cs never did get a flash add-on.)

[legacy]

[35 pages of BDM docs]  Useful, but some information is missing there.

Wait - I could swear the last time I looked at your reply, it said that you had "all the manuals" so this was irrelevant? I have the 1989 CPU32 manual, which has 35 pages of BDM info, including a couple timing diagrams

I acquired the full EVS kit, released by Motorola. It comes with the EVS board, the built-in DI debugger, and 10 manuals. But, have you ever read the CPU32 manual? Have you seen the manual itself says that some information is confidential? It means - not released to the public, only to companies affiliated with Motorola.

Years ago I was not thinking Motorola did this kind of strategy, but they did, and this also applies to the TPU32.

Examples I know are:
- Beckman, for the collaboration on spectrometers
- Ford Racing, for the collaboration on sport driving cars

In both of these two cases, I see a lot of customized 332 chip sold by Motorola to them, and as you know customization means, at least, custom microcode in the TPU's ROM. There is a public TPU assembly compiler, decent enough to make you write your own microcode and you can load it into the shared-ram between the CPU32 and the TPU at runtime, if you want it burned into the ROM you have to call Motorola.  Beckman and Ford Racing did that. But the point is that who writes this microcode needs to know a lot of details for the TPU, some of these details are not covered in the public documentation. Anyway, the two persons I have recently met have confirmed what above, showing me manuals with a "confidential warning" on the first page. Besides it seems there was also a professional TPU compiler, more advanced than the one released to the public.

I was shocked, but now I am not surprised by finding this kind of strategy was also applied to the BDM.

Mainly you have a general description, but there are cases in the timing diagram, not covered by the manual, and not discussed in any public document, but they happen with a high probability and if you are not ready to handle they make the iteration unstable, and the BDM freezes. That is what I have experimented in person.

This makes sense since Motorola released this confidential information to their partners to do business with them, whereas the releasing a part of the documentation appeared a good way to attract and make new customers.

It's a common pattern in the strategy, it makes perfect sense.

[legacy]

Good news!!! I acquired a professional compiler, kindly offered by one of these two seniors. I traded my pocket SHARP E500S-Japanese-version calculator (with a micro-trape driver loaded with BASIC scientific programs) for a licensed version of Avocet W/68k. That man is a collector of this kind of Japanese calculators.

Let me say, the calculator was a souvenir I kept as a reminder of Japan when I visited it for the first time in 1997, and it's the best trade ever, since WOW, the Avocet tool is even ten light-years ahead SierraC 

The license is of aFlexLm-kind that can run on any host if you have the dongle attached to the serial port.
It works on Windows XP/32bit (it fails on Windows 10), it compiles faster than every m68k compiler I have ever tried, it supports { 68000, 68008, 68010, 68020, 68030, 68040, 68060, CPU32 }, the generated assembly code is very neat, and this marvelous tool comes with a software simulator and debugger integrated into the same IDE. The interface is comfortable and precise, very well done, you can observe registers, ram with/without differences (what gets modified is colored in red), symbols, you can trigger on events, you have break-points, event-points, class-points, and a lot of views (decimal, hex, floating-point, BCD, etc), and there is also support for the coverage. I am shocked because this technology was made in 1999 and 19 years later it still looks more advanced than every modern IDE I have ever tried.

No doubt, today is Xmas

[legacy]

Do you want me to scan those for you or not?

I have double checked and I don't happen to have these pages covered in the pdf I got from Motorola. I only have a printed manual with these pages, and in a couple of pages, it's written "to have this information, contact Motorola, ... Texas" (there is an address of an office for paper mail). In a couple of pages, it's written: "reserved".

Anyway, it might help people if they want to do a similar project.

I don't happen to have a scanner. Thanks in advance, you can scan them and upload to this website. I am the admin. The link points to an HTTP uloader, hence you don't need an ftp-client. We are preparing resources for MPUs and CPUs, with tools and documentation.

I've also got a dust-covered 68332 eval board of similar

is it EVS/BBC-DI? or EVO?

[legacy]

The Lauterbach ICE-68330 seems THE tool to go since it's an ICE able to debug everything, including the TPU module. This is also a proof that all the documentation between the BDM and the TPU is ... missing in my manuals.

Anyway, it's a marvelous tool! Hard to find, and it seems very very expensive, especially with the probe.
An additional problem: the CPU module on my EVS card is soldered

Awesome: I am adding it to my next Santa Claus's letter 

[westfw]

CPU32-BDM https://drive.google.com/open?id=13tUBaU9b58XVYlFD4N-lR56DT6ASL584I didn't look carefully before (well, I still haven't looked "carefully"), but it almost seems like the CPU32 implements a sort of proto-BDM - there's the serial link, but a lot of operations seem to require fiddling with other signals as well.  (perhaps this is just the consequence of having external memory buses?)
(page 4&5 are at the end of the document.  Oops.)

[Gribo]

Legacy: How do you program your boards? I have to support a design with the 68332, and intend to use the PEmicro Multilink programmer.

[legacy]

Legacy: How do you program your boards? I have to support a design with the 68332, and intend to use the PEmicro Multilink programmer.

Currently, I am operating via an home-made ROM emulator USB-bulk driven. It emulates two ROMs in parallel, and it's fine for the EVS board which have EVEN and ODD ROMs on the 16bit bus of the CPU. But the built-in firmware on the EVS board is a "DBUG32", a monitor that is able to upload stuff in ram. It loads and decodes SREC-S19, but it doesn't understand the S0-header if it contains metadata. It's very raw and wild, but it allows you to see, modify, and fill the ram. This can be re-used to prepare a gdb-bridge. Modern GDB repositories don't support anything about that, and the support they had for some old board, has been recently removed from modern releases. Therefore, it's all up to you.

I haven't yet tried the PEmicro BDM, it's too expensive and it doesn't come with what I want and need, hence I am using the DI-module on the EVS board that comes with a BDM-to-uart debugger, and an LPT cable with a BDM interface. Both of them are driven by a DOS application, the one for the LTP-BDM cable is only able to program the flash, it can't be used to debug. The one on the DI-module does full debugging.


Anyway, the FPGA-BDM adapter I am willing to build will not be a PE replacement for the business/hobby since I am not willing to support anything else except a gdb-bridge for a simplified gdb-server.

p.s.
I am willing to buy a Lauterbach ICE-68330 unit. It's the best ever, and it's the only tool that supports the TPU debugging: this information is completely missing in every public Motorola documentation I have ever read, and probably it's confidential and classified. Hence, if I will get my hands on the ICE I will for sure need to spend a lot of time at reverse engineering it.

The TPU is a wonderful and useful coprocessor. A couple of Beckman's spectrometers are based on 332 and use the TPU for their tasks. My understanding of details is limited.

[legacy]

as toolchain, I am using
- GNU Gcc + binutils
- Sierra C
- Avocet 68K    <----------- this one is the best ever!

they build an SREC file, then I upload it to board via DBUG32 via UART, or I load it into my ROM emulator interface.

DBUG32 can be modified to program a flash. There was around a patch.

[Harjit]

I would love to find an inexpensive USB based BDM solution that allows me to program flash devices connected to the 68332.

I can't get to the flash devices because they are only connected to the 68332.

Any luck finding something?

Very glad you are doing this.

[legacy]

PEmicro Multilink programmer.

which toolchain are you willing to use?

[Harjit]

Willing - GCC / GDB <- I will have to learn it.

If there is something else, if it is super inexpensive, I'm game.

I have a license for SDS which WindRiver and then Intel acquired but it only supports a parallel port based BDM dongle.

[legacy]

Willing - GCC / GDB <- I will have to learn it.

If there is something else, if it is super inexpensive, I'm game.

You have to define inexpensive 

If you mean the money for a purchase: it's open source, but ... it doesn't work out of the box
Hence if you mean time (time is money), well ... you can start with a simple gdb-stub, that is pure software, and uses the supervisor mode + interrupts. This is the most inexpensive time way, and you debug via uart.

The next step is realizing a gdb-bridge for the BDM, and then a gdb-server. This takes A LOT of time.

parallel port based BDM dongle.

this probably is the cable I was talking about. Years ago, there was a schematic on Motorola's ftp, and a DOS program to use it to program flash chip via BDM.

[Harjit]

Fair points. Would love your guidance and thoughts.

I don't know - under $100? This is for a hobby project.

I have SDS's compiler. I may be able to find sources for dBug or dBug32 and use that as a monitor on the target.

Thank you!

[legacy]

sources for dBug or dBug32

we (at DownTheBunker) are collecting resources for old MPUs.
Maybe Elisabeth (Madame) has the source of dBug32.
Somewhere in her loft, where she has floppies and CDROMs archive.

I will ask the first time I see her around 

p.s.
which is the hardware board you are on?

[legacy]

(we can dump ROMs from the EVS, and upload them if they are useful. These couple of ROMs, Even and Odd, contain dBug32)

[sca]

Not sure if this is helpful or not....

I recall reading on the excellent and unfortunately demised Max's Little Robot Shop that he used an Abatron debugger with these devices. They crop up on ebay occasionally for not much, and, IIRC, support USB and Ethernet interface to host.

sca

[legacy]

Not sure if this is helpful or not....

if your memory layout is the same as the EVS board, then it works, hence it may be helpful, I guess.

demised Max's Little Robot Shop

Is there an article about that? If so, can you upload here ?

Abatron debugger with these devices. They crop up on ebay occasionally for not much, and, IIRC, support USB and Ethernet interface to host.

Usually for no less than 200-250 euro, and you specifically need to find a license for a specific target/protocol, e.g. Abatron for "683332/gdb". Besides, the gdb-server support is not so brilliant and doesn't include any TPU-debugging. It's only for the CPU32 core.

[Harjit]

My board is one I designed back in the mid-90s.

It actually uses a MC68376 or MC68336 with AM29F200 x16 flash and two M5M51008 SRAMs. Since it is custom design, I don't think it will map well to the 68332 design.

[westfw]

Quote

I would love to find an inexpensive USB based BDM solution that allows me to program flash devices connected to the 68332.

Surely this consists of "load this short bit of 68332 code that knows how to program the particular flash chips in use, and this buffer containing the data I want to put there, and then let it run until it returns to BDM mode."  The 68332 doesn't have any knowledge at all about the programming algorithms for external flash chips...
This means your hypothetical flash-loader needs to:Put the 332 into debug mode.Write the registers (which are in the RAM address space) to configure RAM.  (It looks like the 332 has 2k of internal TPURAM; I don't know whether that's easier or more difficult to configure than external RAM.)
Load the RAM with your flash-aware code, and a block of data to write to flash.Start execution of the loaded code.Wait for it to finish.(repeat, perhaps only re-writing the data block.)
That doesn't sound awful - in particular, it doesn't seem like it would run into the "complicated" cases where you're trying to force BDM from assorting running states...

[Harjit]

There are two different ways people have done this:
1) Use the BDM to actually run flash cycles - SDS does this
2) Do what you said, download code to RAM, download programming code to RAM, execute from programming code in RAM to program the flash

I have used both cases. Just an hour ago, I found the code for #2. I had forgotten that I had written it.

Right now, I'm stuck with no ability to configure the chip selects on the microcontroller and then write the stuff to RAM. Sigh!

I have a parallel port BDM dongle but no parallel port. I've seen USB to parallel port adapters but I haven't tried them because I think the software bangs on the I/O port directly and that isn't very kosher with Windows or the USB to parallel port adapters. If someone has made this work, that would be great to learn about.

[legacy]

USB to parallel port adapters

usually, they don't work.

We had (note the past, I don't have on hands, I have to search and find it) a modified version of dBug32 able to upload stuff from the uart, and then to program the flash. This is the way you can go.

[westfw]

USB to parallel port adapters

Most of those are actually "printer adapters", and don't support raw access to the pins at all.
You'd think that it would be possible, with all the protection and virtualization features of a modern x86, to build a hardware/software combination that more faithfully duplicated the raw hardware interface of the old parallel port, with arbitrary communications paths in between the x86 application and the actual DB25 connector.  Except for timing, perhaps :-(Is there something that comes close?  It would be good to know!

[legacy]

You'd think that it would be possible, with all the protection and virtualization features of a modern x86, to build a hardware/software combination that more faithfully duplicated the raw hardware interface of the old parallel port, with arbitrary communications paths in between the x86 application and the actual DB25 connector

On Linux, perhaps.

[legacy]

For m68332, there was another monitor, called "CPU32bug".
This one had a patch allowing onboard flash programming.

[sca]

demised Max's Little Robot Shop

Is there an article about that? If so, can you upload here ?

Not that I'm aware of. I've never found a good archive of the site. Shame because it was an excellent, if jealousy inspiring read!

Abatron debugger with these devices. They crop up on ebay occasionally for not much, and, IIRC, support USB and Ethernet interface to host.

Usually for no less than 200-250 euro, and you specifically need to find a license for a specific target/protocol, e.g. Abatron for "683332/gdb". Besides, the gdb-server support is not so brilliant and doesn't include any TPU-debugging. It's only for the CPU32 core.

I've seen them go unsold for a long time - might fall into the 'try a lowball offer' category.

I've no personal experience with these devices though, so can only go from distant memory. Good luck with your search!

sca

[legacy]

Code: [Select]

Motorola 332Bug v1.00
332Bug>
332Bug>help
BC       Block Compare
BF       Block Fill
BM       Block Move
BR       Breakpoint Insert
NOBR     Breakpoint Delete
BS       Block Search
BV       Block Verify
DC       Data Conversion and Expression Evaluation
DU       Dump S-Records
GD       Go Direct (no breakpoints)
GN       Go and Stop after Next Instruction
GO       Go to Target Code
G        "Alias" for previous command
GT       Go and Insert Temporary Breakpoint
HE       Help Facility
LO       Load S-Records
MA       Macro Define/Display
NOMA     Macro Delete
MAE      Macro Edit
MAL      Enable Macro Expansion Listing
NOMAL    Disable Macro Expansion Listing
MD       Memory Display
MM       Memory Modify
M        "Alias" for previous command
MS       Memory Set
OF       Offset Registers
PA       Printer Attach
NOPA     Printer Detach
PF       Port Format
RD       Register Display
RESET    Warm/Cold Reset
RM       Register Modify
RS       Register Set
T        Trace Instruction
TC       Trace on Change of Flow
TM       Transparent Mode
TT       Trace to Temporary Breakpoint
VE       Verify S-Records
332Bug>


[Harjit]

http://www.usbjtag.com/ has a USB BDM device (USB BDM NT) that seems perfect for programming system flash at a reasonable price.

The designer/author is quite responsive i.e. I asked him if he supported the MC68336/MC68376 and he said he didn't but if I sent him the memory map, he would create the XML file for it.

Besides this device, I have not come across anything in this price range.

Given that it is a BDM device, I'm sure a GDB stub could be written / adapted for it.

[legacy]

http://www.usbjtag.com/ has a USB BDM device (USB BDM NT) that seems perfect for programming system flash at a reasonable price.

Thanks. It looks interesting.

GDB stub

GDB-stub is related to the software running on the CPU.
GDB-bridge is a way to translate GDB commands into specific hw-emulator/ICE's commands.

Hence you want a GDB-bridge to make gdb drive the USB-BDM

[westfw]

68302s ("The ISDN Chip") for $5!https://www.bgmicro.com/motorola-mc68en302pv25bt-mpu-m683xx-25mhz-144-pin-lqfp.aspx

[legacy]

good price for a tiny board 

this is weird

Co-Processors/DSP   Communications; RISC CPM

RISC CPM, what?

[legacy]

I got the board already configure but I don't happen to have the documentation of the jumpers used in the M68332-EVS board. Anyone has it? Can make a scanned copy?

thanks 

[technix]

good price for a tiny board 

this is weird

Co-Processors/DSP   Communications; RISC CPM

RISC CPM, what?

That chip is 68302 + built-in 10Mbps Ethernet and DRAM controller. 68302 has two cores inside, one 68EC000, one RISC.

As of BDM, I am about to sic STM32F042 on it again. The STM32 simply bridges between BDM frames and USB HID reports, and it is up to the host software to implement the actual BDM protocol and a GDB server. Downside is that due to the frame-by-frame bridging BDM is rate limited to 17kbps due to USB HID packet rate limit, upside using HID on the USB side and GDB server on the host side does allow easier creation of cross platform host software, since libhidapi abstracts away the OS-specific details of the USB stack, and sockets are standardized across all platforms including Windows. (Faster HID can be achieved by bumping the processor to something that supports USB 2.0 high-speed, like STM32F405 or STM32F722.)

p.s. I have two samples of 68331 on order (and 68010. And 80C286. And my W65C816 and MC68B09 has arrived. Send help.)

[legacy]

RISC CPM, what?

That chip is 68302 + built-in 10Mbps Ethernet and DRAM controller. 68302 has two cores inside, one 68EC000, one RISC.

RISC is a wrong definition in that description, the built-in TPU engine is not a RISC MPU, it's a timing coprocessor.

[legacy]

The STM32 simply bridges between BDM frames

The problem is not what you want to use to implement the BDM, but rather getting it working in a stable and reliable way, which means reverse engineering all the details that are NOT known from the public documentation. These details do the difference.

I need time to complete the reverse engineering of the DI module of the EVS board, and I need the documentation of CPU module of the EVS board to try a different configuration, specifically how to ignore the ROM0-1 and bootstrap from the ROM2-3

ROM0-1 is a PLCC UV_ROM (16bit ROM) chip soldered on the CPU module
ROM2-3 are a couple of DIP UV_ROM (8bit, ODD and EVEN) mounted on the motherboard, they can be removed, hence I can use my ROM-emulator

This information should be covered in the manual of the EVS board, unfortunately, I don't have. It's not a problem, simply this would make the activity more comfortable since currently I have to upload files via the serial, which is good, but it's slow at max 9600bps while the ROM emulator uploads at 1-2Mbps.

and USB HID reports

Talking about Linux, HIS is not neat for this. USB-bulk is better.

[technix]

RISC CPM, what?

That chip is 68302 + built-in 10Mbps Ethernet and DRAM controller. 68302 has two cores inside, one 68EC000, one RISC.

RISC is a wrong definition in that description, the built-in TPU engine is not a RISC MPU, it's a timing coprocessor.

It is not TPU but a whole another processor, with its own separate bus bridges to the 68EC000 core through a block of dual port SRAM.

[technix]

The STM32 simply bridges between BDM frames

The problem is not what you want to use to implement the BDM, but rather getting it working in a stable and reliable way, which means reverse engineering all the details that are NOT known from the public documentation. These details do the difference.

The whole point of not implementing protocol details in USB to BDM hardware other than the 17-bit framing is so that getting it work is entirely a host side endeavor. This way there would be a chance of recycling existing M68k code in GDB.

and USB HID reports

Talking about Linux, HIS is not neat for this. USB-bulk is better.

When you throw Windows in the mix HID would be much better an option, due to it not requiring any signed drivers or in-MCU additional code for WinUSB. While slow, HID is the most widely supported protocol, and the HID report protocol provides one-to-one framing for the BDM messages.

Or we can use USB CDC ACM as the protocol. Shows up on the host as a serial port, supported by Windows 10 natively, but we need to supply our own framing protocol.

[westfw]

The 68302 does NOT have Ethernet on chip, and the “RISC communications controller” was pretty far from user-programmable.
It could interface directly to ISDN transceiver chips and extract the 2B+D hdlc-like data channels, plus a UART, so it made for a good part of a consumer-level isdn router, or a router interface.  I think I still have one sitting in a cabinet; it was very disconcerting to have my corporate-sponsored 128kb get passed by consumer DSL and cable connections.

[technix]

The 68302 does NOT have Ethernet on chip

The 68EN302 has onboard Ethernet though, and that is what the link goes to.

[legacy]

the “RISC communications controller” was pretty far from user-programmable.

in fact, it's not a RISC CPU, but rather a sort of super simple scheduler made in hardware and able to execute dedicated tasks concerning channel's timing. The keyword of this chip is "channel". It has several channels (physically a pin, or a couple of pins), which can be assigned a Timing-Task.

e.s.
assign the TimingTask "asynchronous serial receiver, 1bit start, 8bit data, 1bit stop" to channel0
assign the TimingTask "asynchronous serial transmitter, 1bit start, 8bit data, 1bit stop" to channel1

makes you have a full-duplex UART assigned to pin Ch0 and Ch1 
(I have personally done several times to have additional UARTs)

The compiler for this "beast" is not a common assembler. It's weird from this point of view and it needs a special manual for learning how to program.

Motorola took the decision to give the final users three possibilities

• option-1: buy the chip with a preprogrammed TPU_ROM, containing predefined tasks able to be assigned to a TPU channel. Several sets of predefined TPU_ROM exist for the public, and the last "letter" in the chip refers to implemented TimingTasks in the TPU_ROM
• option-2: for a large volume of chip purchased, it was possible to ask Motorola to put customized TimingTasks in the TPU_ROM (as masked ROM)
• option-3: program and load your own TimingTask in the TPU_RAM

Beckman and Ford-Racing opted for option-2 


I was ironic about, that "RISC CPM" (and wtf "CPM" means?) was as funny as no-sense

[technix]

I have a general design for my BDM module: just implementing it as an alternative mode in my full-size DAP42 probe. BDM frames are being carried using CMSIS-DAP vendor-specific commands. As of signals BDM lines are mapped to ARM JTAG ones:

* BERR -> TMS/SWDIO
* BCLK -> TCK/SWDCK
* DSI -> TDI
* DSO -> TDO/SWO
* DS -> nTRST
* nRESET -> nSRST
* FREEZE -> RTCK

DAP42 CMSIS-DAP interface has the both string “DAP42” and “CMSIS-DAP” in it. I don’t have my own USB VID yet so I am currently hijacking Ingram’s old VID with 0002:DA42. (The VID 0002 is listed as obsolete, so I take that the chance of collision is low.)

[Gribo]

Hi all,
 I have a board based on the 68332, and a PE micro Multilink FX (USB), I have an executable (.elf) file that I want to run on it.
On an older setup, GDB, Cygwin, Windows XP and a parallel port, I got it to run without an issue. How can I do it on a Windows 7 machine? I managed to get GDB with m68k to run on Cygwin.

[legacy]

I have a board based on the 68332

which board is it?

I managed to get GDB with m68k

We (at DTB) are working on this, but we are busy at the moment with another completely different projects so we will be back on the FPGA-BDM-bridge in summer 

[Gribo]

The board is a customer's board. Practically, 68332, RAM, Flash and tons of 74AC244s.
I can program the flash, using the PEmicro Prog32Z. The board is a known good unit, that is, the production firmware can be programmed and run.
I have found a prebuilt GDB tool chain from SysProgs. The challenge is to use the USB Multilink adapter.

[Gribo]

Just got a reply from PE micro that they don't support the GDB, MultilinkFX and the 68332 combination, and don't have plans to support it. 

[legacy]

I have found a prebuilt GDB toolchain from SysProgs. The challenge is to use the USB Multilink adapter.

Ah, ok, so want a GDB_bridge to the USB Multilink, which implements the BDM v1 protocol.
It would be interesting seeing how that GDB_bridge has been implemented, and what it actually implements.  Probably it's without any support, so you can only have a GDB_stub on your target and talking serially to it. But I can be wrong. Anyway, that's will be a long trip.

[Harjit]

Came across this that people working with BDM on MC683xx parts may find interesting.

Python based using STLink for USB Blaster function:
https://github.com/Najsztub/BDM_UsbBlaster