Software Development for ColdFire Evaluation Boards.
Main evaluation board: M5235BCC. Secondary board: M5282LITE.
PhLoM VME module with JTAG chain XC18V04->XC18V04->XC2V1000 (PROM->PROM->FPGA).
All test files are located at client/jtag directory.
Implemented on both boards M5235BCC and M5282LITE.
Configuration of PROM. Tested successfully using file phlom_prom.xsvf. Programming time 20s.
Configuration of FPGA. Tested successfully of using file phlom_fpga.xsvf. Programming time 8s (cache disabled). Comment1.
Implemented on both boards M5235EVB and M5282EVB.
Tested successfully using idcode.jbc file.
Implemented on both boards M5235BCC and M5282LITE.
Tested successfully using idcode.jam file. All OK.
Tested successfully using phlom_fpga.stapl (generated directly by IMPACT). All OK.
Tested successfully using phlom_prom.stapl (generated directly by IMPACT). All OK.
Is based on colilo and patch for MCF5235. The original S-Record of an image, compiled for SDRAM, is gzipped and relocated for flash address area. The resulted S-Record can be downloaded to flash using dBug or, preferably, CF Flasher. Comment 2.
The only board M5235BCC is supported.
<<upload x ~/n3c/client/jtag/phlom_fpga.xsvf << xplay x x
The same operation in release 263 (cache off) took 14 seconds.
This is due to delays in the XSVF file needed to erase the PROM.
<< upload xp ~/n3c/client/jtag/phlom_prom.xsvf << xplay xp x
<< upload xj ~/n3c/client/jtag/idcode.jam <<splay xj xread_idcode
<< upload xj ~/n3c/client/jtag/idcode.jbc <<splay xj xread_idcode
Release 296
<< upload xs ~/n3c/client/jtag/phlom_fpga.stapl << splay xs xrun_xilinx_proc
With cache enabled takes 8.5 seconds, with cache disabled 48.0 s
1.1 Release 296. Error: Can't connect to 192.168.0.2
<< upload xu ~/n3c/client/jtag/phlom_fpga_user.xsvf << xplay xu x
after that it loses connection to n3c.py, https is OK, the play finished succesfully.
1.2 Sometimes the uploaded files is corrupted. Indication – premature finish of the play, re-uploading usually helps.
Both problems 1.1 and 1.2 could be related to concurrency in the null-event-loop. A fix was implemented in release 297: a lock ProcessPacketAssistance. The errors seems to be disappeared since then.
SPXFEM board version 26 succesfully tested, the pedestals from SVX4 are clean, see Users Guide. The repository of fpga development moved from ./docs/hardware to ./fpga.
In PhLoM board implemented JTAG access to internal registers. JTAG USR1 register (fixed 16-bit) is used as command registers, upper 4 bits define address of internal registers which will be accessed through USR2, the lower bits are used as a command. The length of the USR2 may depend on the command, by default it is 32 bit-wide.
Bugs fixed in example.c (ProcessPacketAssistance) and in jtag.c (shifting in USR registers).
Cache enabled.
Tested successfully for
board M5235
XSVF
JBC
JAM using idcode.jam
Not tested for
board M5282
Not working for
JAM using phlom_prom.stapl
Bootloader added. Bootloader not tested on M5282. The rest should be OK.
Cache off. Everything is working.
Tested successfully for
board M5235
board M5282
XSVF
JBC
JAM using phlom_prom.stapl
Test file phlom_fpga.xsvf. It plays the file successfully to the end but FPGA is not activated. The problem traced to RUNTEST directive. For PROM devices it is used as a time delay but for VIRTEX devices it should send clocks. Program micro.c is modified so that it always sends clocks. Ideally it should be tuned to generate TCK every microsecond, in that case it will serve as a delay as well as a clocker.
The CFInit is very nice GUI for generating initialization code for ColdFire processors. Unfortunately the generated code requires some (minor) patching; i.e. the provided clock setting seems to be not optimal. Probably the best use of the CFInint is for generating pieces of initialization codes for particular devices.