Fixup of EHCI debug device implementation #2
Conversation
implemented putchar() based on I2C to enable printf() use an I2C slave for reception
improved error checking and handling astyle'd the code
the program will now look for the master PID for connecting
use relative path for vend_ax.hex
the function does not take any arguments use SETUPDAT[] instead - otherwise the descriptor handler will just receive garbage and render the device useless
use a #define to enable debugging via I2C
remove unneeded code, only minimal stubs needed for code to compile fixed and added some documentation fixed LED initialisation
stripped down full-speed interface, as the EHCI spec anyways demands for a high speed device
added note on possible issue if no I2C slave is available
added signal handler for Ctrl-C for graceful exiting
|
Glad its useful for you. I'm not sure what to do with pull requests these days. We've moved on from our FX2 projects. We still have a couple projects using FX3 and even a CX3 but mostly we've even moved on from those and have been working on Embedded Linux systems. So in the mean time, I haven't really got a way to verify changes and provide any type of quality control to the original project any longer. In short, FX2lib has pretty much been abandoned. It's probably been several years even since there was a post on the mailing list. |
|
I understand your point - I would feel the same about that. For me the FX2LP boards were a 'quick' way to get EHCI debug running, as these were the devices I had readily at hand. There are likely better solutions (FT232H, BBB) nowadays. Also I did not look into the master dongle code, but I believe there are also some issues, as the dongle will sometimes halt the boot process of the device being debugged... As said, I will leave this PR open in case others run into similar issues and my changes are also there for anyone to see via my repository. |
Hello @night199uk,
First of all, thank you for you additions and @djmuhlestein for the initial implementation (even tough it did not work for me 😅)!
I came across this project via https://www.coreboot.org/DIY_EHCI_debug_dongle, as I needed to build such a dongle to debug issues with coreboot.
Unfortunately, even though the
testbinary indicated success (after some massaging and soldering), I was not able to use the dongle for EHCI, as coreboot was not finding the device. In need of debugging the debugging device I have implementedputchar()via I²C (as UART is not available on the 56-pin chips) and found out, that the slave'shandle_get_descriptor()is receiving a bogus value of 0x68 asdescargument instead of 0x0a (DT_DEBUG). As a consequence it never returns the DEBUG descriptor, which is looked for by coreboot.I was scratching my head for some time before I realised, that the function does not take any argument! The compiler (
sdcc) just won't complain about it... So by removing the argument and usingSETUPDAT[3](which equals wValueH) instead, I was able to get the device recognised as debug dongle (this change can be found in commit 9ed0347). EZ-USB® Technical Reference Manual FTW!As I was at it, I found some other small bugs and also removed unnecessary parts of the code and the descriptor. As I am using Linux, I have also fixed the
terminalapplication a bit.This is the first time I did anything with these FX2LP devices I had once ordered - so I am not sure if I fixed everything correctly. It works for me™.
In hindsight it would have been easier to order an FT232H than to go down that rabbit hole, but now that's it's up and running I would like to share my work in case others might benefit of it.
I don't know if you want to merge in this PR after all these years of inactivity on this project. I will keep the changes public in my repository, anyway.
Cheers,
tempura