Author Topic: m68332 BDM and …. gdb ???  (Read 25876 times)

0 Members and 1 Guest are viewing this topic.

Offline westfw

  • Super Contributor
  • ***
  • Posts: 4196
  • Country: us
Re: m68332 BDM and …. gdb ???
« Reply #75 on: October 13, 2018, 03:28:04 am »
68302s ("The ISDN Chip") for $5!https://www.bgmicro.com/motorola-mc68en302pv25bt-mpu-m683xx-25mhz-144-pin-lqfp.aspx
 

Offline legacyTopic starter

  • Super Contributor
  • ***
  • !
  • Posts: 4415
  • Country: ch
Re: m68332 BDM and …. gdb ???
« Reply #76 on: October 13, 2018, 11:35:53 am »
good price for a tiny board  :D

this is weird

Quote
Co-Processors/DSP   Communications; RISC CPM

RISC CPM, what?
 

Offline legacyTopic starter

  • Super Contributor
  • ***
  • !
  • Posts: 4415
  • Country: ch
Re: m68332 BDM and …. gdb ???
« Reply #77 on: October 16, 2018, 02:25:55 pm »
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  :D
 

Offline technix

  • Super Contributor
  • ***
  • Posts: 3507
  • Country: cn
  • From Shanghai With Love
    • My Untitled Blog
Re: m68332 BDM and …. gdb ???
« Reply #78 on: October 16, 2018, 05:32:09 pm »
good price for a tiny board  :D

this is weird

Quote
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.)
 

Offline legacyTopic starter

  • Super Contributor
  • ***
  • !
  • Posts: 4415
  • Country: ch
Re: m68332 BDM and …. gdb ???
« Reply #79 on: October 16, 2018, 06:41:12 pm »
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.
 

Offline legacyTopic starter

  • Super Contributor
  • ***
  • !
  • Posts: 4415
  • Country: ch
Re: m68332 BDM and …. gdb ???
« Reply #80 on: October 16, 2018, 07:02:07 pm »
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.
 

Offline technix

  • Super Contributor
  • ***
  • Posts: 3507
  • Country: cn
  • From Shanghai With Love
    • My Untitled Blog
Re: m68332 BDM and …. gdb ???
« Reply #81 on: October 16, 2018, 07:20:01 pm »
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.
 

Offline technix

  • Super Contributor
  • ***
  • Posts: 3507
  • Country: cn
  • From Shanghai With Love
    • My Untitled Blog
Re: m68332 BDM and …. gdb ???
« Reply #82 on: October 16, 2018, 07:30:26 pm »
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.
 

Offline westfw

  • Super Contributor
  • ***
  • Posts: 4196
  • Country: us
Re: m68332 BDM and …. gdb ???
« Reply #83 on: October 17, 2018, 07:03:25 am »
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.



 

Offline technix

  • Super Contributor
  • ***
  • Posts: 3507
  • Country: cn
  • From Shanghai With Love
    • My Untitled Blog
Re: m68332 BDM and …. gdb ???
« Reply #84 on: October 17, 2018, 07:08:14 am »
The 68302 does NOT have Ethernet on chip
The 68EN302 has onboard Ethernet though, and that is what the link goes to.
 

Offline legacyTopic starter

  • Super Contributor
  • ***
  • !
  • Posts: 4415
  • Country: ch
Re: m68332 BDM and …. gdb ???
« Reply #85 on: October 17, 2018, 10:53:38 am »
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  :D
(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  :D


I was ironic about, that "RISC CPM" (and wtf "CPM" means?) was as funny as no-sense
« Last Edit: October 17, 2018, 12:17:37 pm by legacy »
 

Offline technix

  • Super Contributor
  • ***
  • Posts: 3507
  • Country: cn
  • From Shanghai With Love
    • My Untitled Blog
Re: m68332 BDM and …. gdb ???
« Reply #86 on: October 17, 2018, 11:55:31 am »
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.)
« Last Edit: October 17, 2018, 12:32:40 pm by technix »
 

Offline Gribo

  • Frequent Contributor
  • **
  • Posts: 629
  • Country: ca
Re: m68332 BDM and …. gdb ???
« Reply #87 on: February 06, 2019, 01:31:27 pm »
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.
I am available for freelance work.
 

Offline legacyTopic starter

  • Super Contributor
  • ***
  • !
  • Posts: 4415
  • Country: ch
banning for things you don't care is pure idiocy
« Reply #88 on: February 06, 2019, 02:13:57 pm »
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  :D
« Last Edit: February 08, 2019, 12:51:01 pm by legacy »
 

Offline Gribo

  • Frequent Contributor
  • **
  • Posts: 629
  • Country: ca
Re: m68332 BDM and …. gdb ???
« Reply #89 on: February 06, 2019, 02:54:47 pm »
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.
I am available for freelance work.
 

Offline Gribo

  • Frequent Contributor
  • **
  • Posts: 629
  • Country: ca
Re: m68332 BDM and …. gdb ???
« Reply #90 on: February 06, 2019, 03:24:21 pm »
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.  |O
I am available for freelance work.
 

Offline legacyTopic starter

  • Super Contributor
  • ***
  • !
  • Posts: 4415
  • Country: ch
Re: m68332 BDM and …. gdb ???
« Reply #91 on: February 06, 2019, 03:27:17 pm »
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.

 

Offline Harjit

  • Regular Contributor
  • *
  • Posts: 141
  • Country: us
Re: m68332 BDM and …. gdb ???
« Reply #92 on: September 26, 2021, 09:07:26 pm »
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
 


Share me

Digg  Facebook  SlashDot  Delicious  Technorati  Twitter  Google  Yahoo
Smf