On Wed, 2011-04-06 at 17:45 +0200, Laurent Gauch wrote: > The EZ-USB gives access to USB but not to the ULINK interface. Right ?
The ULINK consists of the EZ-USB microcontroller, an SRAM, an EEPROM and level shifters. There's even a schematic floating around the net: http://www.mikrocontroller.net/attachment/51828/ULink.pdf Keil is just using the digital I/O of the EZ-USB to read/write the JTAG signals, quite simple actually. On Wed, 2011-04-06 at 18:58 +0200, Michael Schwingen wrote: > > BUT the PROBLEM is to support ULINK interface protocol in OpenOCD, > > since the ULINK protocol specification is not public, but copyrighted > > by KEIL Inc.. > > He wrote that he has written his own firmware, so that would probably > use a different protocol but just run on the ULINK hardware - that would > be perfectly acceptable. Exactly. I have designed my own protocol and implemented it in my custom firmware. I've also written a demo program in C++ that can erase/program flash, read/write fuses, ... in various Atmel AVR (8-bit) devices with my ULINK firmware. > However, if his own firmware needs to be linked against a proprietary > (which we must assume, since no license is given) library, the resulting > firmware binary can not be included in/with OpenOCD. Currently, this is the case. I'll look into alternatives. > However, if the ULINK is basically an EZ-USB chip which downloads its > code via USB, using the ULINK protocol would also mean we would have to > use Keil's firmware, as it needs to be downloaded every time the ULINK > adapter is powered on. Upon power-up, the "blank" EZ-USB chip registers itself with a VID/PID it reads from the EEPROM on the ULINK board. Then, it can at any time be loaded with the firmware program via standard USB control requests, so at no point in time Keil's ULINK protocol needs to be used. On Wed, 2011-04-06 at 18:23 +0200, Øyvind Harboe wrote: > If you want the community to accept your patch, then not only > do you need to pass all the "GPL hurdles", but the community > must be comfortable maintaining your patches and you'll probably > have to do all the work and then some. That is what I'm trying to achieve :) Best regards, Martin _______________________________________________ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
