-
I came across a few sample ADSP-BF532 chips and grabbed them. Now what...? The USB debug adapter, even clones, starts at US$100 even in China. I know that there are open source software tools for that chip. So:
1. How good is OpenOCD support for Blackfin? It is likely my entire chance of using Blackfin will hinge on OpenOCD.
2. Is it possible to hijack another debug probe for Blackfin, like J-Link, ULink2 CMSIS-DAP, or Intel USB Blaster, using OpenOCD?
3. If all above is impossible or difficult, how to find and bootstrap a DIY Blackfin ICE? -
Opensource ... well, you can use a FTDI-2232 chip, forcing it to be a "(jtag) programmer" through OpenJtag, but it will be slow and not comfortable: forget to do any debugging seriously and forget to do any profiling. It's too bad for that. It's usually used for uploading the firmware into ram/flash.Code: [Select]
FT2232H.AD5 --- BFjtag.pin02 EMUdangerous project FT2232 breakout board. Wiring the jtag.
FT2232H.AD3 --- BFjtag.pin06 TMS
FT2232H.AD0 --- BFjtag.pin08 TCK
FT2232H.AC1 --- BFjtag.pin10 TRST
FT2232H.AD1 --- BFjtag.pin12 TDI
FT2232H.AD2 --- BFjtag.pin14 TDO
FT2232H.gnd --- BFjtag.pin04 gndCode: [Select]BFjtagElite-board, jtag connector's pinout
__
1 -|..|- 2 emu
3 -|..|- 4 gnd
5 -|..|- 6 tms
gnd 7 -|..|- 8 tck
gnd 9 -|..|- 10 /trst
gnd 11 -|..|- 12 tdi
gnd 13 -|..|- 14 tdo
+--+
You need to reprogram the EEPROM, making the chip looking like it was a fake-gnICECode: [Select]VID:0x0456 gnICE <------ you need this
PID:0xf000 gnICE <------ you need this
GnICE cable. Original cable. To be "emulated" by dangerous project FT2232 breakout board.
It's cheap, but not so good, and limited to OpenSource: GnICE can't be used with VisualDSP++.
The best *EVER* is VisualDSP++ v5 and its debugger "B1000" cable!
I have a copy of it for Windows XP/32bit, it requires a license, node-locked to the machine. It's the best experience for every professional purpose, it worth the money, and I am 100% satisfied!
A complete kit, based on BF537, i.e. the "Elite-board" + a B1000 cable is still listed at 240 euro (got mine at Farnell). However, since it's going EOL, you may find a discount shot that can be bought for 140 euro.
That is a true bargain if you consider that just the price of the cable is 120 Euro at least. -
Opensource ... well, you can use a FTDI-2232 chip, forcing it to be a "(jtag) programmer" through OpenJtag, but it will be slow and not comfortable: forget to do any debugging seriously and forget to do any profiling. It's too bad for that. It's usually used for uploading the firmware into ram/flash.
This is going back to my "hijacking an existing JTAG probe" idea. What is the software running on top of OpenJTAG? Can it be redirected to use libjaylink and talk to my J-Link clone? Or use a CMSIS-DAP compatible probe like a U-Link 2 clone or the Atmel ICE? Or some other FT2232/FT245 based solution like Intel USB Blaster clone?Code: [Select]FT2232H.AD5 --- BFjtag.pin02 EMUdangerous project FT2232 breakout board. Wiring the jtag.
FT2232H.AD3 --- BFjtag.pin06 TMS
FT2232H.AD0 --- BFjtag.pin08 TCK
FT2232H.AC1 --- BFjtag.pin10 TRST
FT2232H.AD1 --- BFjtag.pin12 TDI
FT2232H.AD2 --- BFjtag.pin14 TDO
FT2232H.gnd --- BFjtag.pin04 gndCode: [Select]BFjtagElite-board, jtag connector's pinout
__
1 -|..|- 2 emu
3 -|..|- 4 gnd
5 -|..|- 6 tms
gnd 7 -|..|- 8 tck
gnd 9 -|..|- 10 /trst
gnd 11 -|..|- 12 tdi
gnd 13 -|..|- 14 tdo
+--+
You need to reprogram the EEPROM, making the chip looking like it was a fake-gnICECode: [Select]VID:0x0456 gnICE <------ you need this
PID:0xf000 gnICE <------ you need this
GnICE cable. Original cable. To be "emulated" by dangerous project FT2232 breakout board.
It's cheap, but not so good, and limited to OpenSource: GnICE can't be used with VisualDSP++.
The best *EVER* is VisualDSP++ v5 and its debugger "B1000" cable!
I have a copy of it for Windows XP/32bit, it requires a license, node-locked to the machine. It's the best experience for every professional purpose, it worth the money, and I am 100% satisfied!
A complete kit, based on BF537, i.e. the "Elite-board" + a B1000 cable is still listed at 240 euro (got mine at Farnell). However, since it's going EOL, you may find a discount shot that can be bought for 140 euro.
That is a true bargain if you consider that just the price of the cable is 120 Euro at least. -
OpenOCD has no support for Blackfin; it wouldn't even know how to halt the processor, much less flash it or make any use of the debug facilities.
OpenJTAG with gnice supposedly works. Maybe just get one of those. https://blackfin.uclinux.org/doku.php?id=hw:jtag:gnice -
OpenJTAG with gnice supposedly works
it can only be used to program an external flash/put a binary into ram, through the jtag.
But it's slow, and, as I wrote: forget debugging and profiling. -
Ah, that's a bummer... I guess AD never released info on its debug support. That makes it a dead end IMO since you're stuck with their ICE kits and their compiler, apart from uclinux.
-
I guess AD never released info on its debug support
They sell VisualDSP++, and B1000 cables, that comes with a full support under VisualDSP++
Why should they support opensource?
In the CD you find inside the Elite-kit, you find CoNix, that is a sort of VirtualPC made for WindowsXP.
There is also a copy of gcc and binutils, plus patches to make them for Blackfin. But there is no jtag-debugger. The only support is gdb, to be used with ucLinux through a serial cable.
That means nothing professional, it's an educational low cost solution, for those can't buy VisualDSP++ and a B1000 cable. -
So before I can pony up that $100 those BF532 chips are dead then?
-
In the CD you find inside the Elite-kit, you find CoNix, that is a sort of VirtualPC made for WindowsXP.
There is also a copy of gcc and binutils, plus patches to make them for Blackfin. But there is no jtag-debugger. The only support is gdb, to be used with ucLinux through a serial cable.
That means nothing professional, it's an educational low cost solution, for those can't buy VisualDSP++ and a B1000 cable.
That seems to be a substantial mis-characterization of why those are there. It's not to be a budget alternative, but rather to support running uClinux on the Blackfin, for applications which want to do a lot of "ordinary computer things" (especially with regards to networking or UI) with a little bit of DSP. In that case, unless you are doing lots of low-level kernel development, you don't need a hardware debugger, just as 99.99% of the time you don't when working on a PC. Even when writing a custom kernel driver, as I did for some BF537 systems a decade ago, it's not likely going to be of that much help.
In contrast, VisuallDSP is for more DSP-driven applications where traditional computer tasks take a back seat. And because things like ftp'ing the development build of an application program into the system and running it from ramdisk don't apply there, nor does operating system assisted debugging in user context, you do need the hardware debug adapter for such work.
-
In contrast, VisuallDSP is for more DSP-driven applications
of course, uclinux on a DSP is more a market way to promote Blackfin.
In my career, I have developed a lot of traditional DSP-driven apps. -
I came across a few sample ADSP-BF532 chips and grabbed them. Now what...? The USB debug adapter, even clones, starts at US$100 even in China. I know that there are open source software tools for that chip. So:
1. How good is OpenOCD support for Blackfin? It is likely my entire chance of using Blackfin will hinge on OpenOCD.
2. Is it possible to hijack another debug probe for Blackfin, like J-Link, ULink2 CMSIS-DAP, or Intel USB Blaster, using OpenOCD?
3. If all above is impossible or difficult, how to find and bootstrap a DIY Blackfin ICE?
COPY the design from Open DSP ICE kit, look at their HP ADSP ICE-530
-
I only found sales links and they costs US$500+. Not helping...I came across a few sample ADSP-BF532 chips and grabbed them. Now what...? The USB debug adapter, even clones, starts at US$100 even in China. I know that there are open source software tools for that chip. So:
1. How good is OpenOCD support for Blackfin? It is likely my entire chance of using Blackfin will hinge on OpenOCD.
2. Is it possible to hijack another debug probe for Blackfin, like J-Link, ULink2 CMSIS-DAP, or Intel USB Blaster, using OpenOCD?
3. If all above is impossible or difficult, how to find and bootstrap a DIY Blackfin ICE?
COPY the design from Open DSP ICE kit, look at their HP ADSP ICE-530 -
OpenADSP has full line of ADI JTAG controller clones.
Those are even more expensive than the genuine ones here in China. -
I have a second ICE1000 lying around, PM me your offer if you want it. The Kaneko BF706 can be included for free. It was modified to tap power directly from USB port. I used this board to develop my BlackFin+ USB Audio Class 2.0 driver stack.
Even though I definitely wish to make an offer, either I would still not be able to afford it, or the price would be so low-ball you wouldn't be able to accept it. I wouldn't want to leave a sour taste in your mouth after this. Please tell me you are ready to brace yourself for some shocking offers, or I would have to put this case to rest for now. The ICE-1000 does look like a nifty little unit though.
It was previous blown up (ESD circuitry and level shifters) and repaired. It works now.
Its 14P connector has been removed and its 10P connector has been removed and replaced with 0.05" ribbon cable with an IDC connector.
The pinout is for Kaneko System's mini 706 and mini 707 boards.
Its MiniUSB port has been modified with MicroUSB port.
Also even if I bought your spare unit, I would still need to mod its target connectors back to stock. The microUSB connector is a nice mod though, and I am even hoping to perform this on my PICkit and ST-Link. I am interested in finding out why the output protection circuit got blown up. What happened? -
Consider you also need VisualDSP++/v5.*, that requires Windows XP/32bit.
-
Consider you also need VisualDSP++/v5.*, that requires Windows XP/32bit.
Just throw it into a virtual machine. -
Sorry to hear that... That must have been an expensive accident. For me the most chip I have blown up so far is a $7 STM32.I am interested in finding out why the output protection circuit got blown up. What happened?
Incorrect vbus connection blew up DSP, DSP blew up debugger.
It is actually kind of a tight month for me financially since I just paid for my next year of Apple Developer Program subscription. Sorry for that ruining a potential deal, and I do understand that if I want to get into ADSP again I will likely have to pay at least US$200 for a new kit.
BTW, what is the development kit for the SigmaDSP line like ADAU1701 or ADAU1761? I have a Bluetooth Hi-Fi project that uses that ADAU1761 DSP in place of the I2S codec, with the intention of implementing some software-defined filtering and equalizing, nulling out the imperfect response of the analog front end and the headphone. -
For info Blackfin support in OpenOCD support is not in mainline but is being worked on and available - http://openocd.zylin.com/4168/
-
Funny, that this topic still comes up every few years. Unfortunately, Analog Devices has run puzzling strategies with their tools, eventually, it seems they left the OpenSource stuff orphaned. The irony is, that the old VDSP very much bases on an old GCC port (yes indeed, ADI never much cared about GPL).
You might find some old distributions of the ICEbear (classic) JTAG software (bfemu/gdbproxy) that work with any FT2232 adapter (if you try hard enough).
On a side note: the ICEbearPlus JTAG is still available, but not 'low cost' in the sense of 'below 100 USD', and support for HW debugging is stripped (flash programming only).
Other than that, fully functional gcc distributions are still maintained and perform (IMHO) better than the mutilated ELF VDSP++ variants.
-
For info Blackfin support in OpenOCD support is not in mainline but is being worked on and available - http://openocd.zylin.com/4168/
Nice!
When will it show up in git@github.com:ntfreak/openocd.git ?
That's what I sync my fork to (git@github.com:bson/openocd.git), just to add RTOS support for my own obscure bare-metal runtime (enetcore).
Ah, I see it's not in master yet, just in a tarball available from... AD! Is this stuff in a branch yet?
-
I think it will likely take a while before it can be merged, since ADI is simply dropping a code blob passively, instead of assigning engineers into actively integrating that code blob into mainline.For info Blackfin support in OpenOCD support is not in mainline but is being worked on and available - http://openocd.zylin.com/4168/
Nice!
When will it show up in git@github.com:ntfreak/openocd.git ?
That's what I sync my fork to (git@github.com:bson/openocd.git), just to add RTOS support for my own obscure bare-metal runtime (enetcore).
Ah, I see it's not in master yet, just in a tarball available from... AD! Is this stuff in a branch yet? -
Funny, that this topic still comes up every few years. Unfortunately, Analog Devices has run puzzling strategies with their tools, eventually, it seems they left the OpenSource stuff orphaned. The irony is, that the old VDSP very much bases on an old GCC port (yes indeed, ADI never much cared about GPL).
I think that pure Digital Signal Processors started their sunset at the same time the opensource was being adopted by big semi manufacturers in the mid 2000s. Nowadays there is a variety of offers, with AD more or less stuck in the past, NXP and TI having moved forward in certain spots of their product line.
You might find some old distributions of the ICEbear (classic) JTAG software (bfemu/gdbproxy) that work with any FT2232 adapter (if you try hard enough).
On a side note: the ICEbearPlus JTAG is still available, but not 'low cost' in the sense of 'below 100 USD', and support for HW debugging is stripped (flash programming only).
Other than that, fully functional gcc distributions are still maintained and perform (IMHO) better than the mutilated ELF VDSP++ variants. -
For me I have some audio based projects in mind that might need dedicated digital signal processors.Funny, that this topic still comes up every few years. Unfortunately, Analog Devices has run puzzling strategies with their tools, eventually, it seems they left the OpenSource stuff orphaned. The irony is, that the old VDSP very much bases on an old GCC port (yes indeed, ADI never much cared about GPL).
I think that pure Digital Signal Processors started their sunset at the same time the opensource was being adopted by big semi manufacturers in the mid 2000s. Nowadays there is a variety of offers, with AD more or less stuck in the past, NXP and TI having moved forward in certain spots of their product line.
You might find some old distributions of the ICEbear (classic) JTAG software (bfemu/gdbproxy) that work with any FT2232 adapter (if you try hard enough).
On a side note: the ICEbearPlus JTAG is still available, but not 'low cost' in the sense of 'below 100 USD', and support for HW debugging is stripped (flash programming only).
Other than that, fully functional gcc distributions are still maintained and perform (IMHO) better than the mutilated ELF VDSP++ variants. -
Yes, you are using the correct tool for the job. True DSPs are unbeatable for signal processing.
For me I have some audio based projects in mind that might need dedicated digital signal processors.Funny, that this topic still comes up every few years. Unfortunately, Analog Devices has run puzzling strategies with their tools, eventually, it seems they left the OpenSource stuff orphaned. The irony is, that the old VDSP very much bases on an old GCC port (yes indeed, ADI never much cared about GPL).
I think that pure Digital Signal Processors started their sunset at the same time the opensource was being adopted by big semi manufacturers in the mid 2000s. Nowadays there is a variety of offers, with AD more or less stuck in the past, NXP and TI having moved forward in certain spots of their product line.
You might find some old distributions of the ICEbear (classic) JTAG software (bfemu/gdbproxy) that work with any FT2232 adapter (if you try hard enough).
On a side note: the ICEbearPlus JTAG is still available, but not 'low cost' in the sense of 'below 100 USD', and support for HW debugging is stripped (flash programming only).
Other than that, fully functional gcc distributions are still maintained and perform (IMHO) better than the mutilated ELF VDSP++ variants.
If you are still looking for options, I am very familiar with the C674x family of floating point DSPs, where you can start for somewhat less money: the C6748 LCDK is $195.00, but the advantage is that it can be programmed with a cheaper FTDI-based XDS100v2 (clones everywhere) or a bit faster XDS110 (there is the official version and a clone called XDS110Lite). The mainstream IDE (Code Composer Studio) still actively supports it and costs nothing. There is even a SDK still supported. -
I do have a few sample chips of TMS320VC5509A. Older series than C674x but should work reasonably well.
Yes, you are using the correct tool for the job. True DSPs are unbeatable for signal processing.
For me I have some audio based projects in mind that might need dedicated digital signal processors.Funny, that this topic still comes up every few years. Unfortunately, Analog Devices has run puzzling strategies with their tools, eventually, it seems they left the OpenSource stuff orphaned. The irony is, that the old VDSP very much bases on an old GCC port (yes indeed, ADI never much cared about GPL).
I think that pure Digital Signal Processors started their sunset at the same time the opensource was being adopted by big semi manufacturers in the mid 2000s. Nowadays there is a variety of offers, with AD more or less stuck in the past, NXP and TI having moved forward in certain spots of their product line.
You might find some old distributions of the ICEbear (classic) JTAG software (bfemu/gdbproxy) that work with any FT2232 adapter (if you try hard enough).
On a side note: the ICEbearPlus JTAG is still available, but not 'low cost' in the sense of 'below 100 USD', and support for HW debugging is stripped (flash programming only).
Other than that, fully functional gcc distributions are still maintained and perform (IMHO) better than the mutilated ELF VDSP++ variants.
If you are still looking for options, I am very familiar with the C674x family of floating point DSPs, where you can start for somewhat less money: the C6748 LCDK is $195.00, but the advantage is that it can be programmed with a cheaper FTDI-based XDS100v2 (clones everywhere) or a bit faster XDS110 (there is the official version and a clone called XDS110Lite). The mainstream IDE (Code Composer Studio) still actively supports it and costs nothing. There is even a SDK still supported.
I still would like to keep my options open though. For the current audio processing workload I am evaluating five options:
* Blackfin (ADSP-BF531)
* SigmaDSP (ADAU1761)
* TMS320C55xx series (TMS320VC5509A)
* Cortex-M4F (STM32F405RGT6)
* Cortex-M7F (STM32F722RET6)