BDI3000 Replacement

[tarun172]

All,

I have inherited a project that utilizes PowerPC along with a BDI3000 programmer. Since the BDI3000 has reached its end of life (EOL), I would like to replace it with a more current programmer. From my research, it seems that the Segger J-Flash could be a suitable replacement. Unfortunately, updating the hardware design is not an option. Has anyone gone through this upgrade process before? If so, I would appreciate any insights or advice you could share.

Thanks,

[mon2]

Is your BDI3000 defective? Will check but we may have a new, not used BDI3000 at the office. Would that be of interest to you?

[Eternauta]

The PEEDI from Ronetix has support for Power Architecture (see list below). Setup is similar to BDI200 via description file for core and memory.

MPC5200, MPC5121, MPC5123, MPC5125
MPC55xx: MPC5510, MPC5514, MPC5517, MPC5534, MPC5553, MPC5554, MPC5565
MPC56xx: MPC5566, MPC5567, MPC5634M, MPC5644A, MPC5675
MPC57xx: MPC5745R
Support for SPE and VLE instruction sets
Power Architecture QUICC II: MPC83xx, MPC8313, MPC8315, MPC8321, MPC8343, MPC8347, MPC8349
Power Architecture QUICC III: MPC85xx
Power Architecture QorIQ: P1010, P1020, P2040, P4080, BSC9131
Power Architecture QorIQ, e5500 64-bit: T1040
Power Architecture QorIQ, e6500 64-bit: T2080, T4240
PowerPC: PPC405, PPC440, APM82xx

[tarun172]

Hi mon2,

Thank you for your offer. We currently have two BDI3000 programmers. However, setting up the BDI3000 can be quite time-consuming, so I was wondering if there might be a simpler JTAG alternative available. After reviewing the NXP website, it seems there aren’t many viable options.

I appreciate your input on this matter.

Best regards,
tarun172

[DiTBho]

PowerPC along with a BDI3000 programmer

Which one?
Here PPC40*, ~603 core

I think the development environment makes the difference, for example, ironically Green Hills and Windriver do not support ICEs that are supported by GDB.

-

I have Green Hills stuff at work for { PPC440, PPC460 PPCE500 }.
I work on PPC/embedded on daily basis, and I like it even for personal projects, but since what I use at work is very expensive (>50K euros, hw + sw) I'm using cheap solutions at home for my hobby stuff.

For example, as practical personal project, I created an X11 terminal with a ppc405, GNU/linux uclibc nanoX11 based, because the cpu clock is 133Mhz, it must be the lightest possible; I needed a Jtag to fix some bugs in the firmware (uboot), to make the PCI video card (MGA, G450, dual VGA screen) initialize correctly (the second channel was not initialized) and to fix a problem that prevented every 128 Mbyte SDRAM stick (PC133) from being recognized correctly (wrong rank) and from working (wrong CTAS timing).

I worked without a jtag during these processes, I just used a ROM emulator(1) to convert "uboot" from a version that runs only in flash (default profile by Denx), to a version that is copied to RAM and runs entirely in RAM.

Why was it so important? Well, because this way, if the CPU fetches from RAM, you can use a proper GDB-stub to "run-time" replace instructions with opcodes break exceptions, and this allows for very simple debugging (breakpoints) with the simplest "gdb-stubs" that talks on the serial line at 19200bps.

It is very invasive, slow, and you cannot do it if the CPU fetches from the ROM of the devices, whhich is a big limitation, but it is still better than nothing.

With an ICE you can do "code injection" directly into a special buffer and force the CPU to fetch from there, without having to modify the RAM in any way.

So... the BDI2K or BDI3K was clearly better, and every now and then I searched the internet for debuggers for sale.
One day I found a brand new BDI2K abandoned in a remote warehouse in the USA.
Talking to people there, they offered for less than 200 euros + S/H + importing fees.

Great upgrade! it was new but there was no firmware CD, something you have to buy separately, and it is specific to the target you want to support.

The CD contains the firmware that you then need to load into the debugger.
So you have to buy a special CD for PPC40x, a special CD for PPC44*, ... etc., a special CD for MIPS32, a special CD for ARM-v7, and so on.
There are many options.

At the time, I didn't have any firmware CD and spent months looking for it, so I haven't found the time to put it to good use yet and for sure I'll only try as "gdb-upgrade".

-

In short
I wouldn't want any "replacements" to create you the same type of problem I had, where you have the debugger's hw but not the firmware you need to make it work with the desired target 


edit:
(1) In theory, if I had a ROM emulator that allowed to modify just one byte at a time instead of an entire page of memory, I could use it for an entirely software-based GDB-stub approach, without the need to modify uboot to run enterely in RAM.

[DiTBho]

setting up the BDI3000 can be quite time-consuming

Green Hills comes with scriptable functions to setup debuggers and ICEs, as well as examples and templates.
I know, since it's an expensive product there are paid guys who provide them, even for custom boards rather than for development boards (e.g. Ebony, Sequioia, etc).

Don't you have setup examples and templates? 

[Pseudobyte]

I am not sure what your actual target hardware is.

This might be interesting for you to investigate further: (seems to have different licensing depending on which power architecture you are targeting)
https://microcontrollershop.com/product_info.php?products_id=1706&osCsid=mtmcvlg2nb0r355ts1ljfqpgo1

I opened up the j-link gdb server and it does list some PowerPC targets. I'd test it for you if I had hardware.

List: