Sunday 23 June 2019

The Motorola DSP56L307EVM signal processing board

Some information to get a Motorola dsp56L307evm digital signal processing evaluation board from 2001 working on a linux computer in 2019.

The dsp56002evm (top) and dsp56l307evm (bottom)
This is a kind of a next step after getting my old dsp56002evm working under linux.

Introduction


The dsp56L307 is a 24bit (dsp) processor and can run at 150MHz. Together with the Enhanced Filter Coprocessor (efcop) it can generate 270MIPS. I will need to do some real benchmarking, but it can probably be compared with something like a STM32F407 (arm-M4 core at 168MHz) for the calculation speed.However the 24bit Harvard architecture with 3 memory spaces makes it still different and not fully comparable with an arm-M4, which is probably much better in quite some tasks..

I have bought my board from "littlediode" on ebay. While not advertised as such, it did came as the full original EVM kit in original box; that is with documentation, software, power adapter and cable.


The first challenge is to find, roughly 15 years after discontinuation and changing the company from Motorola to Freescale to NXP, all the documentation and tools back in the archives. My board did come with a CD with software like assembler and simulator, but that was not the latest version. The box did not include DSP specific test software for the board.

The wayback machine, does help a bit to find old pages, manuals(pdf) and software back. There are Motorola related pages and Freescale related pages that can be found back. It is advisable to browse a bit between the different snapshots to try to try to find what you are looking for. Another source are old university pages; this dsp was used for some courses.

 Then are all the tools that can be found only for dos / windows available, which gives inherently inconveniences for using those tools on Linux.


Most of the dos/windows tools can be used under a wine console, this shares at least the filesystem. For the dsp56002EVM was it partly needed to use dosbox / dosemu to get the debugger working, which is way more cumbersome in usage.

My current status is:
  • I can use the official (windows) tools and IDE for writing and compiling code.
  • I can use openocd to upload the code and inspect memory and registers to validate the working. (It is not real debuging, for that I would need gdb)
The next sections give a bit more information for this.

Setting up the (Windows) toolchain

The latest version of the required tools are part of the Freescale Symphony studio. This package contains the assembler, linker, c-compiler and tools to change the COFF files in a more universal format.
To get the eclipse based IDE working is it necessary to install an old  Java runtime. I was able to get one from oracle. This does need an account / login.

After installing this with "wine" then we get three sub directories in the install directory:

├── [4.0K]  dsp56720-devtools 
│   ├── [4.0K]  dist
│   │   ├── [4.0K]  dsp56720
│   │   ├── [4.0K]  gcc
│   │   │   ├── [4.0K]  bin  <-- directory with all the tools !
│   │   │   ├── [4.0K]  dsp
│   │   │   ├── [4.0K]  etc
│   │   │   └── [4.0K]  lib
│   │   ├── [4.0K]  gdb
│   │   └── [4.0K]  openocd
│   │       ├── [4.0K]  bin
│   │       └── [4.0K]  driver
│   ├── [4.0K]  doc
│   └── [4.0K]  licenses
├── [4.0K]  eclipse <-- directory with "startsymphony.bat" to start eclips based IDE
│   ├── [4.0K]  configuration
│   ├── [4.0K]  features
│   ├── [ 12K]  plugins
│   └── [4.0K]  readme
└── [4.0K]  sample-projects
    ├── [4.0K]  ASM-Tutorial
    │   └── [4.0K]  Debug
    └── [4.0K]  C-tutorial
        └── [4.0K]  Debug
The batch file to start the eclips based IDE is setting some paths which are necessary for the tool chain to work correctly.  These paths have to be set as well when we want to use the tools, for instance the gcc based c compiler, outside of the IDE. The contents of the batch file is:

~/.wine/drive_c/Symphony-Studio/eclipse$ cat startsymphony.bat 
@echo off

set DDT_HOME=C:\Symphony-Studio\dsp56720-devtools
set G563_EXEC_PREFIX=%DDT_HOME%\dist\gcc\lib\
set PATH=%DDT_HOME%\dist\gcc\bin\;%PATH%
set DSPLOC=%DDT_HOME%\dist\gcc

start C:\Symphony-Studio\eclipse\symphony-studio.exe

exit

The Symphony-studio program can also be started from the start menu. It does look to have sometimes problems to start properly; the windows stay empty. A bit clicking and loading some files seem to help.
The Symphony-studio IDE with assembler output.
With some well chosen command line options is it also possible to get the C-compiler working from the wine console.

$ wineconsole
C:\Symphony-Studio\dsp56720-devtools\dist\gcc\bin>g563c -BC:\Symphony-Studio\dsp56720-devtools\dist\gcc\lib hola.c -o hola.cld

The assembler can also be used stand-alone:

$ wineconsole
C:\Symphony-Studio\dsp56720-devtools\dist\gcc\bin>asm56300 -A -lpass.lst -B pass.asm

Setting up OpenOCD

The current OpenOCD (version 0.10.0) as some issues and is not fully supporting the dsp563xx anymore. The register structure is asking for an "exist" parameter which was missing. And the read and write functions for the memory have an incorrect word size definition. I have submitted two patches to openocd to solve this. The patches can also be found here.  Depending when this is read can this be already included in the latest openocd version.

Further more is a configuration file for openocd needed to make the jtag interface, target and board work together.  This  is still work in progress. The contents for the target is for now as follows:

$ cat dsp5gl307.cfg
if { [info exists CHIPNAME] } { 
   set _CHIPNAME $CHIPNAME
} else {
   set _CHIPNAME dsp56L307
}

if { [info exists ENDIAN] } { 
   set _ENDIAN $ENDIAN
} else {
  # this defaults to a big endian
   set _ENDIAN big
}

if { [info exists CPUTAPID] } {
   set _CPUTAPID $CPUTAPID
} else {
   set _CPUTAPID 0x0181101d
}
#jtag scan chain
jtag newtap $_CHIPNAME cpu -irlen 4 -ircapture 1 -irmask 0x03 -expected-id $_CPUTAPID
#target configuration
set _TARGETNAME $_CHIPNAME.cpu
target create $_TARGETNAME dsp563xx -endian $_ENDIAN -chain-position $_TARGETNAME
#working area at base of ram
$_TARGETNAME configure -work-area-virt 0

And for the EVM board I have made the following configuration file:
$ cat dsp56l307evm.cfg
# Script for freescale DSP56L307EVM
#
# the build in wiggler Jtag interface
source [find interface/parport.cfg]
#jtag speed
adapter_khz 100
reset_config trst_and_srst
# Some additional delays to improve the initialisation.
adapter_nsrst_delay 100
jtag_ntrst_delay   20

source dsp56l307.cfg

#setup flash 
#missing for now; did not work yet

proc enable_fast_clock {} {
    # Programm a factor of 5 into the PLL 
    # 12.288MHz * 3 = 36.8MHz
    mwwx 0xFFFFFD 0x060002
    # enable a timer to see a LED flashing
    mwwx 0xFFFF8F 0x000021
}
# initialize only board specifics - reset, clock, adapter frequency
proc init_board {} {
    global _TARGETNAME
    
    $_TARGETNAME configure -event reset-start {
        # Removed the system reset to be able to have the platform run
        reset_config trst_only
        adapter_khz 500
    }

    $_TARGETNAME configure -event reset-init {
        # this will be done only once!
        # perform a tap and system reset to be sure that the memory is cleared
        reset_config trst_and_srst
        enable_fast_clock
        adapter_khz 500
    }
}

I will upload the final version (when the flash is also working) to git for inclusion into the openocd source.

When starting and working with openocd you should get something as on the pictures below:
Starting openocd with the dsp56l307evm.cfg config file
Connecting with telnet to the debug session

The dsp653xx target of openocd uses a special parameter "memspace" in which of the 4 memory spaces the data is put:
Set memspace #
  • 1 gives access to X data memory  (MEM_X = 0)
  • 2 gives acces to Y data memory (MEM_Y = 1)
  • 3 gives access to the combined X and Y memory called L memory (MEM_L = 3).
  • all other values result in access to P memory or program memory (MEM_P = 2)
This can be used to load data in all memory spaces as follows:

> set memspace 0  # set P memory as default
> load_image program.p 0x0 s19

> set memspace 1   # set X memory as default
> load_image program.x 0x0 s19

> set memspace 2   # set Y memory as default
> load_image program.y 0x0 s19


Checking if open ocd is working by programming one of the timers:
> mwwx 0xFFFF8F 0x21
> mdwx 0xFFFF8F

To change the PLL we can do this:

> mwwx 0xFFFFFD 0x060002    <--  PLL (2+1)=3 x 12.288MHz = 36.864MHz
> mwwx 0xFFFFFD 0x060008    <--  PLL (8+1) =9 x 12.288MHz = 110.592MHz
> mwwx 0xFFFFFD 0x06000B    <--  PLL (11+1) =12 x 12.288MHz = 147.456MHz

Which makes the timer go faster as well.

SREC

The (windows) SREC tool can be used to convert the special CLD COFF files to something more universal that can be loaded by openocd to program the dsp.
This tool has to be run with the following options:
$ srec -r -t 4 infile.cld 
The two necessary options are:
  • The -r option is needed to flip the direction of the words to fix the Endianness difference between host and the dsp. 
  • With the -t 4 option are the words expanded from 24 bit to 32bit.
this image can be loaded by openocd onto a target:
> load_image infile.p 0x0 s19

This srec tool can be called from the Symphony IDE to convert the files after compiling.