Hey all -
I'm attempting to write an *.img file to the FX3 (sitting on the FX3 DVK board) from the command-line on a GNU/Linux system, and am receiving a return code of -9. I have a couple of questions:
1) Can bix, hex, ihx, etc., files be written to the FX3 RAM / EEPROM, as you could with the FX2, or do they need to be img files?
2) Are these the only instructions regarding how to write firmware directly to the FX3 RAM?
I would love to see a more in-depth instruction list, but that is the only thing I have been able to find so far.
3) Is there a location that I can look up the error codes, e.g., the '-9' that I am seeing now?
Tools based on the fx2lib project: http://sourceforge.net/projects/fx2lib/develop
What of my other questions? What is the best way to push firmware onto the FX3 from the command line, and where can I find documention regarding the error codes?
Thanks for your time!
Just to clarify, I realize that the FX chips have only ever supported *.img internally - I'm talking about programs that will convert/upload over the wire.
This is the least important of my questions, as you can turn any of the listed hex/bin files into an img file - it's just a format.
The more important questions are:
1) What is the best way to program firmware from the command line for FX3?
2) Where is documentation for return codes?
Thanks for your time!
We do not support the utility that you're using. So I don't have information on the error code or how it works.
I agree with your point on format change but you do realize that you're something that was meant for FX2/FX2LP with FX3.
Currently control center is the utility for downloading firmware. We don't have a command line for firmware download at this point of time.
Here you go,
It uses 0xA0 vendor request similar to FX2LP but here since the address is 4-byte long we use wValue for Least Significant Word and wIndex for Most Significant Word of the address. Using this we send the data.
After this at the end we send the jump to program entry vendor request (same 0xA0 vendor request format as above but with wLength as 0 bytes) with the address to jump to in wValue and wIndex. (similar to 0xA0 vendor request to 0xE600 in the case of FX2LP to let the CPU execute code).
FYI, I posted a patch to fxload to support download of an .img file to FX3 RAM:
I am not sure whether fxload is being maintained (I haven't received any response yet on the patch), so don't look for it in mainline anytime real soon...
Hi, I was trying to follow your instruction and apply your patch to the current release of FX2Lib on sourceforge (version 0.1).
But looking at the patch you’ve published I suspect the patch is meant to be applied to a different version of fx2lib.
At the first line you are diffing your code against ezusb.c which doesn’t exists on the latest release of FX2lib. Which version and where do I find the FX2lib source you’ve used?
Thanks in advance, Joel
I based the patch on the CVS tree:
It looks like majordomo damaged the patch by scrubbing out e-mail addresses that were embedded in the code. A clean copy of the patch is attached. I verified that this applies to the CVS fxload project.
I run into a similar problem as the OP when trying to follow the procedure described above. When issuing a control transfer as follows, I receive an error from the device at 0x4000 (-9: LIBUSB_ERROR_PIPE if the control request was not supported by the device).
int r = libusb_control_transfer( usbhdl, // handle 0x40, // bmRequestType: Host to Device, Vendor, Device 0xA0, // bRequest: Vendor dl_addr_low, // wValue (LSW) dl_addr_high, // wIndex (MSW) (unsigned char*)d, // data bs, // wLength 1000 ); // timeout in ms
Essentially, this means I can't download firmware files > 16384 bytes.
Sorry for the (presumably) bad formatting here. There's neither a preview nor decent formatting capabilities
I found myself jumping through the hoops to get the fxload utility updated for the FX3 per Steven's instructions, so I though I'd save fellow seekers some time by branching off of the abandoned fxload project.
Behold the fx3load project on SourcefForge which incorporates Steven's patch and includes a 32-bit linux executable:
Thanks! I never did get any response to my attempt to send the changes to fxload upstream, so I guess "abandoned" is the right word.
It would be nice to port fxload's ability to program flash on the target device. Control Center seems to use CyBootProgrammer.img for this; for fx3load, I suppose we'd have to develop an equivalent .img that can adapt to whatever SPI/I2C flash it finds.
Can anyone from Cypress comment on whether such an .img could be bundled with (GPLv2) fx3load?