m68332 BDM and …. gdb ???

[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?