I have an fw.hex file compiled wth Keil that works good on my FX2 Dev Board and loading it with the Control Panel. Now I'm writing a C# Windows Application to work with it. I'm using the provided cyusb.dll. and I can't get it to load fw.hex to RAM. I always get false when calling LoadRAM("myfile.hex"). I even tried an example App that came with SuiteUSB cyusb.dll that uses that same funtion and I get the same result. Could LoadRAM() method be broken in the dll or there are some special compiling options, or program size or what could it be? Please I need help, and cypress forums won't do anything. Regards, Gabriel Camiro
Just an update. I've tried loading LED Cycle which is 227 bytes long and it loads good. Anything larger won't load. Might be some size factor?
I've not used SuiteUSB, but watch Cypress regularly. :-)
What is the version of SuiteUSB ? Recently, Cypress put this web page
SuiteUSB.NET 2.0 (2) Last Updated 2 Jul, 2008
On this page, they distribute newer version of SuiteUSB download.cypress.com.edgesuite.net/.../suiteusb_net_2_0___usb_development_tools_for_visual_studio_2005_and__net_2_0_3_0_19.msi
The former version was 2_0_3_0_14.
Tsuneo
I will check that. Any other method to load my .hex to the external memory of FX2?
Well I have the newest version of the cyusb.dll. What I read is that LoadRAM() is wouldn't load programs to external memory. So how does the supplied Control Panel does to load programs to fx2?
"What I read is that LoadRAM() is wouldn't load programs to external memory."
The expression of the reference has misled you.
"The LoadRAM method of CyFX2Device writes the contents of an .iic or a .hex file to the internal RAM of an FX2 device and then, re-starts the device, running the new downloaded firmware. The file containing the firmware image is named in the fwFile paramter."
This "internal" RAM means on-chip XRAM, which serves also as CODE space. Anyway, you cannot run any firmware on IRAM.
Well FX2 has only 8k or RAM for that purpose. So my firmware is 10k and most of the sample firmware are bigger than that. So how is it loaded to the Chip. It has to be running on external RAM in the 128k chip in the dev board. Am I wrong?
I don't think the routine distinguishes on-chip XRAM and external one, because hardware configuration (EA pins) does it. Firmware cannot select on-chip or external.
Original FX2 had 8KBytes on-chip XRAM, current FX2LP extends it to 16KB.
Did the new version fixes the bug?
No, I have the latest software and same results. I wonder how to load firmware manually?
I think i have the same problem: I cannot download a firmware bigger than 11ko in the internal RAM of the FX2LP. To download into the internal RAM, the FX2 has a Vendor command (0xA0, see FX2 Datasheet). I think that Cypress tools uses this command. to download into external RAM, a loader must be downloaded into internal RAM before.
When I compile my firmware with Keil tools, I have no error message, but I cannot execute it on the target.
In my firmware, I have two different vendor commands. If I compile it separately, (program size is under 11Ko), it runs, but If i compile the firmware with both commands (program size is above 11ko) it crashes!!
I think that if I program a firmware loader that is small enough that I can load it from eeprom to internal memory at power-up. Then transfer the code with EP0 to the FX2 and the loader firmware movx data to external memory and reenumerate. Does that sound like a good idea? Now, any help on that would be thanked! Gabriel Camiro
I found another post that solve my problem: http://www.keil.com/forum/docs/thread6363.asp
In the linker I have to configure the code area starting at address 0x200 otherwise when code size is greater than 11ko the linker put code at address 0, when area between 0x00 and 0x80 is reserved for FX2. I hope this solution resolve your problem too.
Pascal
Let me check that out and I'll post results.
Pascal,
I don't think the topic is so useful. http://www.keil.com/forum/docs/thread6363.asp
It just says Ran Shalgi's problem seems to be fixed temporarily by "change linker settings to start code placement at 0x200 and onwards." And the reason that Ran Shalgi and Erik suggested are wrong.
Ran Shalgi wrote, "Cypress initialization code copies the USB descriptors to RAM address 0x80."
There is no such function on EZ-USB. The USB descriptor is provided by the firmware code. And On the EZ-USB architecture, CODE and XDATA spaces share the same XRAM. Why does it need to copy the USB descriptors?
Also, even if such function would be there, why the problem is not revealed until the code size grows? As the default, KEIL linker always stuffs the code space from the low address first.
And Erik suggested FIFO/GPIF Autovector of EZ-USB extended interrupt. Actually, this vectors are placed on 0x0480 - 0x04B4. It's beyond the problematic address, 0x0200 Then, this vectors are completely irrelevant to the issue.
This autovector is enabled by AV4EN=1 in the INTSETUP register. Did you enable this flag?
"In the linker I have to configure the code area starting at address 0x200 otherwise when code size is greater than 11ko the linker put code at address 0, when area between 0x00 and 0x80 is reserved for FX2."
On the code space, 0x0000-0x0080, reset and interrupt vectors are placed. The linker handles this space properly, as long as you use "interrupt" specifier correctly, without extra linker setting. Then, this is not the reason why you need the extra linker setting.
Check the map file (.M51) for CODE and XDATA assignment.
Programming is not a voodoo magic. Find out the real reason and fix it. Otherwise, you'll get into trouble again.