Coldfire BDM with the prop

Ale

Here is the code and the description of the circuit used. The Source contains some comments and points to be taken into account because the manual is a bit loose in details, sometimes.
MIT License applies

** Original Text **
I got this project I'm working on, a remake of some propeller powered board where I need a bit more memory and much more speed. Going back and forth I decided to use the Coldfire 5206e (got 3 of them some years back). Programming tools using BDM are quite expensive I mean plenty expensive. As the protocol is written down in the manual I decided to use it for a propeller powered dongle that can talk to the CF but with a small catch... it will not need a PC !, at least for simple things. The propeller can easily drive a monitor and keyboard and talk to the CF. Of course downloading something will require a PC... but in principle it should be doable. The cf board is not yet ready but think I can make this work.
btw... this CF stuff looks outdated but the parts are still in production. I wonder if they were ever successful....

Any thoughts ?

****
Release Notes 1.005 - 16.04.2011

All commands except GO and RESET are implemented. Downloading to the target is also not yet implemented but individual bytes/words/longs are implemented.
Read the source for comments on hw interface.

For the 5206e a good start is:

WC MBAR 1
WL 68 F000003E
WC RAMBAR 10001

Relocates the module to the address 0
Relocates CS0 to F000000 and disables all accesses to it
Relocates the internal SRAM to 10000

Note: if CS0 is not disabled by writing the CSMR0 all accesses to memory will not complete !
More initialization may be needed, I'm testing that right now.

Enjoy !

Ale

I see that nobody commented, as i thought the coldfire seems to be less than popular at least among hobbysts. They are nice processors but I think that the cost of the programming tools.make them not so attractive. I'll post news along the development path.
Something more to add is that an external eeprom could be used to hold the program to debug/load to help in the process, a sd card can be used too.

Tubular

Ale, I assume the BDM protocol for the CF is essentially the same as the one used to program the MC9S08 series micros?

If so it would be useful to be able to program up slave processors from the prop, by wrapping their code into an Obex object.

It may also be a cost effective way to add peripherals of the CF that might be useful to the prop.

Ale

The protocol is not similar, I will have to have a look at the specifics for other micros to see where i can add some flexibility to allow easy extension. It is also used in HC12 MC683xx and maybe in the ppc based processors.
Edit: read below!

Ale

The HC08 family BDM is very differernt from that of the CF series as it uses only one pin for bidirectional communication. Of course the propeller can cope with such a protocol. Maybe a separated object will be needed to support this family...
The HC12 uses also a 1-wire protocol like the HC 08.

vettezr1

yea which CF board are you using I have a few of the 68030s and 40s I do have mc68hc11s but they are really hard to use I think it would be a cool project to do

Ale

I am designing my own board. It is almost finished. I have a mfc5206e, 4MB SRAM (2 cycle access) and a FPGA as perpherial controller. You can get one bare board if you want. I already connected a 020 to the propeller (look for the pPropQL020 project) and now I want something a bit more powerful. The 030 is not much more difficult than the 020 but you also need some glue logic. I can give you some pointers if you want. The CF has memory decoding and chip selects built-in so glueless connection of memories is possible.

Ale

Hei,

As I sent the Coldfire board to manufacture the need for the BDM Dongle increased considerably , as in "I need it sort of now" . I designed this circuit using proper level translators. These voltage translators are in my initial design not needed because the Coldfire operates at 3.3 V too but for isolation, lower load and coolness factor... they are there. From a software stand-point they are simply not seen and thus the software needs no re-write .
Any comments are appreciated.

BTW, if anyone is interested there are 2 boards I do not need/do not have parts for (except SRAM and Flash)
Specifications:
MCF5206e Coldfire
4MB SRAM (2 cycle access)
512k Flash
Video, SDCard, 12 bit 1 to 3 Msps ADC controlled via a XC2S100 FPGA with 512kx8 Video and 128kx8 ADC buffer.
Expansion connector
BDM Port (:D)
Connector for Rayman's breakout board for the 4.3" TFT
Connector for PS/2 Keyboard and VGA Monitor
All regulators (5, 3.3, 2.5V are on-board).

Edit: Of course such a dongle can be done with every other processor but a standalone dongle is mostly a propeller's specialty, well I'm sure an ATMega with a 25 MHz clock can do it also but it will not be either so cool or have 80-columns video

Ale

The boards are on their way from China to Germany... so I'll be building the Propeller BDM module really soon... I'll have to test both circuits at the same time as I do not have any other reference (but there is a way to boot the coldfire without BDM... just in case ;-).

Ale

Well, the boards arrived yesterday and I populated one partially so I can start with the propBDM module. I implemented a simpler version with only some resistors in series for all pins. The Processor status and data pins are not yet routed. The board eats 20 mA at 12 V and 74 after a couple of seconds... when the prop boots ? (from nowhere... I assume).

Fotos show the propBDM and the coldfire board. Boards were manufactured in Malaysia, I got 5 pcs for 91 $ (70 € or so), shipped Fed€x to may place. (Thanks octal!)

Note: The board has a yellow LED. LEDs are important... no board that wants to work can miss a LED ;-)

davidsaunders

Thank you. One of the CPUs that I have to work is the Coldfire v4e. I do not like the cost of the interfaces available for these MCUs and am glad to see a much less expensive solution.

Ale

I'd love to put my hands on some v4 !. I went first with the 5206e because I already have them...

Do you have some board/test equipment at your disposal ? we could develop something in parallel... PM me if you want

davidsaunders

No dev-board just a CPU board for the not yet complete MultiDB68K (see: http://davidsaunders.cwahi.net/MultiDB68K/index.html ). I do know that the site does not yet mention the Coldfire CPU board.

Ale

That's a very nice project !
Do you have photos of the boards ? :-)

Ale

It works !!!!!!!!!!!!! Now for something more "spannend" than NOPs ;-)

davidsaunders

Ale wrote:

It works !!!!!!!!!!!!!

Great, this is a big help.

Ale wrote:

Do you have photos of the boards ? :-)

Sorry, I do not have a camera. I really need to get one, as there are many such things I would like to photo.

Ale

I have been working on this and there are a couple of things that are sort of... footnote size (in some manual I did not find yet) .
The commands are 17 bits and the answers too. the first bit is ignored but it is recommended to set it to zero.
The BKPT signal seems to have to be asserted all the time during the DEBUG incursion, otherwise the commands return the status "not ready".

I'm adding now a dump registers command (it will be the first command ) as I took me a while to see all what was going on.
Btw. I'm using the propeller to generate the processor CLK signal, for the time being it is 5 MHz.

When the processor starts D0 is loaded with 0x08100000 and D1 with 0xEFFFAC03... now where I read what those values mean... CFPRM... I think.

This is the response from a write to D2 DEADBEEF and to D3 BABEFACE and then read D2 (the NOP thing was before..):

Here is Pacito's propBDM interface v1.01

The processor is in HALT state (LED should light-up)
Commands (addresses and values in HEX):
D <addr>: Dump memory (LONG)
G : executes the BDM GO command and exits HALT state
H : This help screen
WB <addr> <value>: write byte
WW <addr> <value>: write word
WL <addr> <value>: write long
Have fun
Answer to the NOP command (should be 0000FFFF) :DEADBEEF

>?

Ale

@davidsaunders:

Just a question... do you have in mind Real-Time tracing ? because unless done a low speed (few MHz) the propeller cannot cope with it (I did not implement any of that so far).

davidsaunders

Ale wrote:

Just a question... do you have in mind Real-Time tracing ?

No, Absolutely not.

Ale

I was thinking of adding a serial Flash to the propeller so firmware could be loaded to the flash and then to another Flash on the target.
Which functionality do you need ?
I was planning the following:
- Control register read/write
- Register read/write
- Memory read/write (byte/word/long and dump and bulk transfer to CF's memory, to program the Flash on the target. I'm using a 29F040 on it)

After programming some debugger into Flash I shouldn't need the BDM anymore but just in case the following can be added:

- Debug support: breakpoint set/reset and so on

As soon as I have something sort of usable (more than dump registers) I'll post the code. For the time being the circuit is just a propeller with some series resistors, a crystal and a propplug.

davidsaunders

Ale:
That which you already plan is all I need and then some. Mostly for programming, maybe to dump something if there is an issue. For me there is no need for the breakpoints, and if i need to reset I can always pull the reset line.

davidsaunders

Well, looks like I do not have a Coldfire at the moment. Today is test day for that board, and it has a short somewhere (in the board, the solder connections have been triple checked), probably in a buried layer (it is a 4 layer board).

Ale

Wasn't the board electrically tested by the manufacturer ? (Most 4 layer boards are...) Don't you have an unpopulated board to check ?... I always check before I populate if VDD and GND are not shorted and again when I solder some components. Once I discovered that some solder flowed below a QFP ic shorting everything... that was after I started cutting traces to isolate powered sections .

Edit: I'm really sorry to read that the board has a short. I hope you can fix it, I'm really looking forward to another CF board around ! (maybe we are the only two that still work with CFs ;-) )

davidsaunders

If I can fix it and the CF is not fried (my only one at the moment), then this will be good. If not I will order a couple v2 CFs and redo the board. There is a lot of extra stuff in the V4e that makes it more difficult to deal with, setting up the Flex bus, making sure that certain unused pins are not floating, etc.. Once we have the Propeller II it may end up being faster to emulate the 68k, rather than use a CF with an illegal instruction handler (for the 68k ops, and addressing modes missing from the CF).

I stripped the board already and the board definitely has a short, so do the two that have not yet had anything put on them. Perhaps a design error.

Ale

I'm sorry to hear that all boards have shorts . I have some extra boards if you need something to test on.

davidsaunders

Thank you though I think I will buy a few of these: http://search.digikey.com/scripts/DkSearch/dksus.dll?Detail&name=MCF5270AB100-ND

And get some new boards made.

Ale

That's a very nice part. 3 times the performance of my 06e ! and the same packaging. Good choice specially if paired with 32 bit SDRAM !. I'll have a look at the BDM part to see if there are differences with the 06. So far I can pack everything in the propeller'S memory .

Ale

The '527x has some extra registers, eMAC related, that are accessible via BDM, the rest is the same. I'm using the propeller to generate the processor clock but that is not critical. It is also used to synchronize the DSCLK and to ensure that the frequency is lower than or around CLK/2.

Ale

@davidsaunders: How is your board comming ? What features does it have ?

davidsaunders

Still have not yet ordered the new CF chips. Though these are just alternative CPU boards for the computer as a whole, and as such they do nat use any of the peripherals of the CF. I am using the CF due to the fact that the 680x0 is no longer developed. For the time being I am working with 1 68030 CPU board, and 2 68000 CPU boards, in order to get the system up and running (and make sure that the bus is not Dependant on the clock of any single component [including CPU]).

On the system as a whole; Currently working on getting the video where I want it, Sound is working better than could ever be expected, ATA is working well (though I could use an ATAPI driver for the prop [ATAPI is still somewhat of a mystery to me]), KB & Mouse working, Joysticks working, Amiga OS tries to boot (not quit there yet), AROS tries to boot.

On the CF side I will be getting back with you as soon as I have the chips, and the new board is tested.

Ale

I'm making progress with the software for propBDM. I'm not very proficient at Spin so that part is moving slowly... the assembler driver needs almost no testing ;-), it is very simple. I'm thinking on how to do the downloads of code to FLASH or RAM... the prop has still > 24kbytes free so I may go for a simpler solution in two stages... not quite there yet. I have to find the dataflash chips I have somewhere... no idea where they are I'll post some preview as soon as I have most commands working... may be a few days more.

Edit: There are some undocumented behaviours that I found out testing the code. What has to be done with the BKPT line is the most prominent. I just wonder what happens when the GO command is executed... I'll find out soon , hopefully.