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
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.
Tsuneo