m68332 BDM and …. gdb ??? - Page 1
Forum section: electronics / general

author: legacy
author_rank: Super Contributor
timestamp: July 30, 2014, 11:41:36 am
content: hi guysi am toying with a tiny mc68332 board which has BDM interfaceand i guess if there is a working debug interface for gdb or … anything else aroundlet me know

author: andersm
author_rank: Super Contributor
timestamp: July 30, 2014, 12:26:38 pm
content: Have a look at theBDM toolspackage. Never used it myself.

author: legacy
author_rank: Super Contributor
timestamp: July 30, 2014, 05:57:57 pm
content: yeah, but it seems old, and i'd like to have feedback aboutalso, anybody toying with gdb-stub for m68k ?

author: westfw
author_rank: Super Contributor
timestamp: July 30, 2014, 08:04:30 pm
content: QuoteThe 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.)

author: legacy
author_rank: Super Contributor
timestamp: July 30, 2014, 09:55:58 pm
content: BDM is stills used by freescale, unfortunately they have and sell closed and expensive debuggers and Applicationsand 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

author: nctnico
author_rank: Super Contributor
timestamp: July 30, 2014, 10:55:03 pm
content: 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.

author: legacy
author_rank: Super Contributor
timestamp: July 31, 2014, 07:24:37 am
content: 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.

author: legacy
author_rank: Super Contributor
timestamp: July 31, 2014, 07:30:41 am
content: Quote from: nctnico on July 30, 2014, 10:55:03 pmMotorola 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 cablethe 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 boardsi 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 freeMy problems are:1) such an interface is DOS only, and i can't run DOS on my modern systems2) 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

author: legacy
author_rank: Super Contributor
timestamp: July 31, 2014, 07:35:46 am
content: you are right for those who want professional tools and don't want to spend $500 USD for a P&E USB BDM

author: nctnico
author_rank: Super Contributor
timestamp: July 31, 2014, 07:59:48 am
content: 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.

author: legacy
author_rank: Super Contributor
timestamp: July 31, 2014, 09:18:02 am
content: Quote from: nctnico on July 31, 2014, 07:59:48 amit seems to me like comparing an home made extremely cheap (and limited) download cable with the professional oneedit:btw, i am looking for a good BDM, i am not interested about these considerations.edit2:seethisbdm ICE for hc12, it's very impressive, also the sw interface is cool

author: legacy
author_rank: Super Contributor
timestamp: July 31, 2014, 09:43:23 am
content: i have foundthisproject, OpenSource BDM Interface

author: legacy
author_rank: Super Contributor
timestamp: July 31, 2014, 09:48:10 am
content: andhttps://github.com/osfreedom/bdm-osbdmthis otherbdm-osbdmproject

author: andersm
author_rank: Super Contributor
timestamp: July 31, 2014, 10:20:17 am
content: For hardware interfaces, there'sUSBDMand PE Micro'sOSBDM, but I don't think either supports CPU32.

author: westfw
author_rank: Super Contributor
timestamp: July 31, 2014, 11:00:49 am
content: None of the CPU32 chips have any flash, do they?Coldfire had a $99 bdm adapter...

author: legacy
author_rank: Super Contributor
timestamp: July 31, 2014, 11:21:23 am
content: Quote from: westfw on July 31, 2014, 11:00:49 amnope, 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 ?

author: westfw
author_rank: Super Contributor
timestamp: July 31, 2014, 08:54:57 pm
content: Quotehttps://www.freescale.com/webapp/sps/site/prod_summary.jsp?code=USBMULTILINKBDMI 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...

author: snoopy
author_rank: Frequent Contributor
timestamp: August 01, 2014, 03:14:08 am
content: Quote from: nctnico on July 30, 2014, 10:55:03 pmThat 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 modelI 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 meMy advice to anyone is don't use motorola 68K stuff. The architecture was good in its heyday but is ancient by comparison now.cheers

author: legacy
author_rank: Super Contributor
timestamp: August 01, 2014, 05:44:04 am
content: Quote from: snoopy on August 01, 2014, 03:14:08 ami think the m68K ISA is still the most elegant and easy oneARM is complex, MIPS is much more complex at the assembly levelespecially if you have to deal with pipeline approach!btw, i have already built 2 tiny boards with 68332 on them, it's for hobby purposeso 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 ?

author: snoopy
author_rank: Frequent Contributor
timestamp: August 01, 2014, 06:16:22 am
content: Quote from: legacy on August 01, 2014, 05:44:04 amNo 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

author: bwat
author_rank: Frequent Contributor
timestamp: August 01, 2014, 06:55:58 am
content: Quote from: snoopy on August 01, 2014, 03:14:08 amLauterbach?

author: westfw
author_rank: Super Contributor
timestamp: August 01, 2014, 08:06:56 am
content: 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...

author: snoopy
author_rank: Frequent Contributor
timestamp: August 01, 2014, 01:06:23 pm
content: Quote from: bwat on August 01, 2014, 06:55:58 amyep you guessed itAnd they are still in business today !!

author: snoopy
author_rank: Frequent Contributor
timestamp: August 01, 2014, 01:15:29 pm
content: Quote from: westfw on August 01, 2014, 08:06:56 amIt 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

author: legacy
author_rank: Super Contributor
timestamp: August 01, 2014, 01:41:57 pm
content: Quote from: westfw on August 01, 2014, 08:06:56 ami 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

author: nctnico
author_rank: Super Contributor
timestamp: August 01, 2014, 01:46:35 pm
content: 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.

author: legacy
author_rank: Super Contributor
timestamp: August 01, 2014, 02:04:39 pm
content: Quote from: snoopy on August 01, 2014, 06:16:22 amnope, it depends by your compiler

author: legacy
author_rank: Super Contributor
timestamp: August 01, 2014, 02:10:13 pm
content: Quote from: nctnico on August 01, 2014, 01:46:35 pmyeah, 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.

author: nctnico
author_rank: Super Contributor
timestamp: August 01, 2014, 03:39:16 pm
content: 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.

author: snoopy
author_rank: Frequent Contributor
timestamp: August 03, 2014, 01:59:27 am
content: Quote from: legacy on August 01, 2014, 02:04:39 pmAll 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 youhttp://www.microbeetechnology.com.au/retro_computing.htmcheers

author: legacy
author_rank: Super Contributor
timestamp: August 03, 2014, 11:48:56 am
content: Quote from: snoopy on August 03, 2014, 01:59:27 amthat's true

author: legacy
author_rank: Super Contributor
timestamp: September 22, 2018, 11:29:31 am
content: and years later it's still an unsolved problem

author: westfw
author_rank: Super Contributor
timestamp: September 22, 2018, 08:42:51 pm
content: QuoteI 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.)

author: joeqsmith
author_rank: Super Contributor
timestamp: September 22, 2018, 09:34:39 pm
content: 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.

author: legacy
author_rank: Super Contributor
timestamp: September 22, 2018, 10:39:27 pm
content: Quote from: westfw on September 22, 2018, 08:42:51 pmpartially solved, but it's not a 100% working solution, and I am not 100% satisfied.Quote from: westfw on September 22, 2018, 08:42:51 pmI don't like Arduino, Avr8, and that stuff.

author: legacy
author_rank: Super Contributor
timestamp: September 22, 2018, 10:44:08 pm
content: Quote from: joeqsmith on September 22, 2018, 09:34:39 pmThe 332 is still used in spectrometers and in a couple of Ford Racing's combustions engines.I am specifically interested in both of them.Quote from: joeqsmith on September 22, 2018, 09:34:39 pmwhich one? with which software?Quote from: joeqsmith on September 22, 2018, 09:34:39 pmDoes 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.

author: legacy
author_rank: Super Contributor
timestamp: September 22, 2018, 11:11:35 pm
content: Quote from: legacy on August 03, 2014, 11:48:56 amthis is what I wrote, that meansable 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 builtable 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 lineAfter 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.

author: joeqsmith
author_rank: Super Contributor
timestamp: September 23, 2018, 06:27:46 am
content: Quote from: legacy on September 22, 2018, 10:44:08 pmICE is a Microtek.Quote from: legacy on September 22, 2018, 10:44:08 pmI 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.

author: legacy
author_rank: Super Contributor
timestamp: September 23, 2018, 10:33:20 am
content: Quote from: joeqsmith on September 23, 2018, 06:27:46 amCPU32 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?

author: legacy
author_rank: Super Contributor
timestamp: September 23, 2018, 10:39:30 am
content: Quote from: bwat on August 01, 2014, 06:55:58 amI am evaluating this possibility.

author: legacy
author_rank: Super Contributor
timestamp: September 23, 2018, 11:50:02 am
content: oh, I had forgotten there was alsothistopic, 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 decisionsAnyway, now I am able to fully run the DI protocol on the EVS board by using a DOS laptopedit:andthistopic was about BDM&C

author: joeqsmith
author_rank: Super Contributor
timestamp: September 23, 2018, 04:46:19 pm
content: 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:5ZAAAOSwPkBaVs3Yhttps://www.ebay.com/itm/vintage-EST-SERIES-300-Background-Debugging-System-CPU32-BDM-Port-Manual-J-4/201316508159?hash=item2edf6621ff:g:PE0AAOSwv0tVEwpC

author: legacy
author_rank: Super Contributor
timestamp: September 23, 2018, 07:51:02 pm
content: 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

author: westfw
author_rank: Super Contributor
timestamp: September 24, 2018, 03:09:47 am
content: My CPU32 manual has a 35-page chapter on BDM details. Is this what you have, or would it be useful?

author: legacy
author_rank: Super Contributor
timestamp: September 24, 2018, 07:32:50 am
content: Quote from: westfw on September 24, 2018, 03:09:47 amUseful, but some information is missing there.

author: legacy
author_rank: Super Contributor
timestamp: September 28, 2018, 07:17:32 pm
content: 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

author: westfw
author_rank: Super Contributor
timestamp: September 29, 2018, 03:56:51 am
content: QuoteWait - 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.)

author: legacy
author_rank: Super Contributor
timestamp: September 29, 2018, 09:22:19 am
content: Quote from: westfw on September 29, 2018, 03:56:51 amI 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 carsIn 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.

author: legacy
author_rank: Super Contributor
timestamp: September 29, 2018, 10:00:42 am
content: 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 SierraCThe 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

author: legacy
author_rank: Super Contributor
timestamp: September 30, 2018, 01:48:07 pm
content: Quote from: westfw on September 29, 2018, 03:56:51 amI 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 tothiswebsite. 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.Quote from: westfw on September 29, 2018, 03:56:51 amis it EVS/BBC-DI? or EVO?

author: legacy
author_rank: Super Contributor
timestamp: October 01, 2018, 12:14:53 am
content: TheLauterbach ICE-68330seems 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 solderedAwesome: I am adding it to my next Santa Claus's letter

author: westfw
author_rank: Super Contributor
timestamp: October 01, 2018, 04:39:58 am
content: CPU32-BDMhttps://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.)

author: Gribo
author_rank: Frequent Contributor
timestamp: October 01, 2018, 03:02:23 pm
content: Legacy: How do you program your boards? I have to support a design with the 68332, and intend to use the PEmicro Multilink programmer.

author: legacy
author_rank: Super Contributor
timestamp: October 01, 2018, 03:23:10 pm
content: Quote from: Gribo on October 01, 2018, 03:02:23 pmCurrently, 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 thePEmicro 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 aLauterbach ICE-68330unit. 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.

author: legacy
author_rank: Super Contributor
timestamp: October 01, 2018, 03:28:45 pm
content: 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.

author: Harjit
author_rank: Regular Contributor
timestamp: October 02, 2018, 05:44:14 am
content: 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.

author: legacy
author_rank: Super Contributor
timestamp: October 02, 2018, 05:59:33 am
content: Quote from: Gribo on October 01, 2018, 03:02:23 pmwhich toolchain are you willing to use?

author: Harjit
author_rank: Regular Contributor
timestamp: October 02, 2018, 06:18:33 am
content: 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.

author: legacy
author_rank: Super Contributor
timestamp: October 02, 2018, 06:35:39 am
content: Quote from: Harjit on October 02, 2018, 06:18:33 amYou have to define inexpensiveIf you mean the money for a purchase: it's open source, but ... it doesn't work out of the boxHence 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.Quotethis 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.

author: Harjit
author_rank: Regular Contributor
timestamp: October 02, 2018, 07:06:50 am
content: 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!

author: legacy
author_rank: Super Contributor
timestamp: October 02, 2018, 07:31:49 am
content: Quote from: Harjit on October 02, 2018, 07:06:50 amwe (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 aroundp.s.which is the hardware board you are on?

author: legacy
author_rank: Super Contributor
timestamp: October 02, 2018, 07:36:08 am
content: (we can dump ROMs from the EVS, and upload them if they are useful. These couple of ROMs, Even and Odd, contain dBug32)

author: sca
author_rank: Regular Contributor
timestamp: October 02, 2018, 08:33:43 am
content: 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

author: legacy
author_rank: Super Contributor
timestamp: October 02, 2018, 08:49:47 am
content: Quote from: sca on October 02, 2018, 08:33:43 amif your memory layout is the same as the EVS board, then it works, hence it may be helpful, I guess.Quote from: sca on October 02, 2018, 08:33:43 amIs there an article about that? If so, can you uploadhere?Quote from: sca on October 02, 2018, 08:33:43 amUsually 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.

author: Harjit
author_rank: Regular Contributor
timestamp: October 02, 2018, 09:49:47 pm
content: 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.

author: westfw
author_rank: Super Contributor
timestamp: October 02, 2018, 09:56:55 pm
content: QuoteSurely 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...

author: Harjit
author_rank: Regular Contributor
timestamp: October 02, 2018, 10:04:38 pm
content: There are two different ways people have done this:1) Use the BDM to actually run flash cycles - SDS does this2) Do what you said, download code to RAM, download programming code to RAM, execute from programming code in RAM to program the flashI 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.

author: legacy
author_rank: Super Contributor
timestamp: October 02, 2018, 10:34:11 pm
content: Quote from: Harjit on October 02, 2018, 10:04:38 pmusually, 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.

author: westfw
author_rank: Super Contributor
timestamp: October 03, 2018, 02:01:28 am
content: QuoteMost 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!

author: legacy
author_rank: Super Contributor
timestamp: October 03, 2018, 09:38:30 am
content: Quote from: westfw on October 03, 2018, 02:01:28 amOn Linux, perhaps.

author: legacy
author_rank: Super Contributor
timestamp: October 03, 2018, 09:39:37 am
content: For m68332, there was another monitor, called "CPU32bug".This one had a patch allowing onboard flash programming.

author: sca
author_rank: Regular Contributor
timestamp: October 03, 2018, 10:03:08 am
content: Quote from: legacy on October 02, 2018, 08:49:47 amNot 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!Quote from: legacy on October 02, 2018, 08:49:47 amI'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

author: legacy
author_rank: Super Contributor
timestamp: October 05, 2018, 06:17:53 pm
content: Code:Motorola 332Bug v1.00332Bug>332Bug>helpBC Block CompareBF Block FillBM Block MoveBR Breakpoint InsertNOBR Breakpoint DeleteBS Block SearchBV Block VerifyDC Data Conversion and Expression EvaluationDU Dump S-RecordsGD Go Direct (no breakpoints)GN Go and Stop after Next InstructionGO Go to Target CodeG "Alias" for previous commandGT Go and Insert Temporary BreakpointHE Help FacilityLO Load S-RecordsMA Macro Define/DisplayNOMA Macro DeleteMAE Macro EditMAL Enable Macro Expansion ListingNOMAL Disable Macro Expansion ListingMD Memory DisplayMM Memory ModifyM "Alias" for previous commandMS Memory SetOF Offset RegistersPA Printer AttachNOPA Printer DetachPF Port FormatRD Register DisplayRESET Warm/Cold ResetRM Register ModifyRS Register SetT Trace InstructionTC Trace on Change of FlowTM Transparent ModeTT Trace to Temporary BreakpointVE Verify S-Records332Bug>

author: Harjit
author_rank: Regular Contributor
timestamp: October 08, 2018, 04:08:33 pm
content: 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.

author: legacy
author_rank: Super Contributor
timestamp: October 08, 2018, 09:43:57 pm
content: Quote from: Harjit on October 08, 2018, 04:08:33 pmThanks. It looks interesting.Quote from: Harjit on October 08, 2018, 04:08:33 pmGDB-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

author: westfw
author_rank: Super Contributor
timestamp: October 13, 2018, 03:28:04 am
content: 68302s ("The ISDN Chip") for $5!https://www.bgmicro.com/motorola-mc68en302pv25bt-mpu-m683xx-25mhz-144-pin-lqfp.aspx

author: legacy
author_rank: Super Contributor
timestamp: October 13, 2018, 11:35:53 am
content: good price for a tiny boardthis is weirdQuoteRISC CPM, what?

author: legacy
author_rank: Super Contributor
timestamp: October 16, 2018, 02:25:55 pm
content: 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

author: technix
author_rank: Super Contributor
timestamp: October 16, 2018, 05:32:09 pm
content: Quote from: legacy on October 13, 2018, 11:35:53 amThat 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.)

author: legacy
author_rank: Super Contributor
timestamp: October 16, 2018, 06:41:12 pm
content: Quote from: technix on October 16, 2018, 05:32:09 pmRISCis a wrong definition in that description, the built-in TPU engine is not a RISC MPU, it's a timing coprocessor.

author: legacy
author_rank: Super Contributor
timestamp: October 16, 2018, 07:02:07 pm
content: Quote from: technix on October 16, 2018, 05:32:09 pmThe 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-3ROM0-1 is a PLCC UV_ROM (16bit ROM) chip soldered on the CPU moduleROM2-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-emulatorThis 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.Quote from: technix on October 16, 2018, 05:32:09 pmTalking about Linux, HIS is not neat for this. USB-bulk is better.

author: technix
author_rank: Super Contributor
timestamp: October 16, 2018, 07:20:01 pm
content: Quote from: legacy on October 16, 2018, 06:41:12 pmIt 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.

author: technix
author_rank: Super Contributor
timestamp: October 16, 2018, 07:30:26 pm
content: Quote from: legacy on October 16, 2018, 07:02:07 pmThe 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.Quote from: legacy on October 16, 2018, 07:02:07 pmWhen 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.

author: westfw
author_rank: Super Contributor
timestamp: October 17, 2018, 07:03:25 am
content: 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.

author: technix
author_rank: Super Contributor
timestamp: October 17, 2018, 07:08:14 am
content: Quote from: westfw on October 17, 2018, 07:03:25 amThe 68EN302 has onboard Ethernet though, and that is what the link goes to.

author: legacy
author_rank: Super Contributor
timestamp: October 17, 2018, 10:53:38 am
content: Quote from: westfw on October 17, 2018, 07:03:25 amin 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 channel0assign the TimingTask "asynchronous serial transmitter, 1bit start, 8bit data, 1bit stop" to channel1makes 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 possibilitiesoption-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_ROMoption-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_RAMBeckmanandFord-Racingopted for option-2I was ironic about, that "RISC CPM" (and wtf "CPM" means?) was as funny as no-sense

author: technix
author_rank: Super Contributor
timestamp: October 17, 2018, 11:55:31 am
content: 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 -> RTCKDAP42 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.)

author: Gribo
author_rank: Frequent Contributor
timestamp: February 06, 2019, 01:31:27 pm
content: 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.

author: legacy
author_rank: Super Contributor
timestamp: February 06, 2019, 02:13:57 pm
content: Quote from: Gribo on February 06, 2019, 01:31:27 pmwhich board is it?Quote from: Gribo on February 06, 2019, 01:31:27 pmWe (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

author: Gribo
author_rank: Frequent Contributor
timestamp: February 06, 2019, 02:54:47 pm
content: 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.

author: Gribo
author_rank: Frequent Contributor
timestamp: February 06, 2019, 03:24:21 pm
content: 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.

author: legacy
author_rank: Super Contributor
timestamp: February 06, 2019, 03:27:17 pm
content: Quote from: Gribo on February 06, 2019, 02:54:47 pmAh, 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.

author: Harjit
author_rank: Regular Contributor
timestamp: September 26, 2021, 09:07:26 pm
content: 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