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

0 Members and 1 Guest are viewing this topic.

Online westfw

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

Offline legacy

  • Super Contributor
  • ***
  • Posts: 3273
  • Country: 00
Re: m68332 BDM and …. gdb ???
« Reply #76 on: October 13, 2018, 10:35:53 pm »
good price for a tiny board  :D

this is weird

Quote
Co-Processors/DSP   Communications; RISC CPM

RISC CPM, what?
the Bunker is open!
 

Offline legacy

  • Super Contributor
  • ***
  • Posts: 3273
  • Country: 00
Re: m68332 BDM and …. gdb ???
« Reply #77 on: October 17, 2018, 01:25:55 am »
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
the Bunker is open!
 

Offline technix

  • Super Contributor
  • ***
  • Posts: 2758
  • Country: cn
  • From Shanghai With Love
    • My Untitled Blog
Re: m68332 BDM and …. gdb ???
« Reply #78 on: October 17, 2018, 04:32:09 am »
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 legacy

  • Super Contributor
  • ***
  • Posts: 3273
  • Country: 00
Re: m68332 BDM and …. gdb ???
« Reply #79 on: October 17, 2018, 05:41:12 am »
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.
the Bunker is open!
 

Offline legacy

  • Super Contributor
  • ***
  • Posts: 3273
  • Country: 00
Re: m68332 BDM and …. gdb ???
« Reply #80 on: October 17, 2018, 06:02:07 am »
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.
the Bunker is open!
 

Offline technix

  • Super Contributor
  • ***
  • Posts: 2758
  • Country: cn
  • From Shanghai With Love
    • My Untitled Blog
Re: m68332 BDM and …. gdb ???
« Reply #81 on: October 17, 2018, 06:20:01 am »
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: 2758
  • Country: cn
  • From Shanghai With Love
    • My Untitled Blog
Re: m68332 BDM and …. gdb ???
« Reply #82 on: October 17, 2018, 06:30:26 am »
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.
 

Online westfw

  • Super Contributor
  • ***
  • Posts: 2691
  • Country: us
Re: m68332 BDM and …. gdb ???
« Reply #83 on: October 17, 2018, 06:03:25 pm »
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: 2758
  • Country: cn
  • From Shanghai With Love
    • My Untitled Blog
Re: m68332 BDM and …. gdb ???
« Reply #84 on: October 17, 2018, 06:08:14 pm »
The 68302 does NOT have Ethernet on chip
The 68EN302 has onboard Ethernet though, and that is what the link goes to.
 

Offline legacy

  • Super Contributor
  • ***
  • Posts: 3273
  • Country: 00
Re: m68332 BDM and …. gdb ???
« Reply #85 on: October 17, 2018, 09:53:38 pm »
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, 11:17:37 pm by legacy »
the Bunker is open!
 

Offline technix

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


Share me

Digg  Facebook  SlashDot  Delicious  Technorati  Twitter  Google  Yahoo
Smf