We are running a survey to help us improve the experience for all of our members. If you see the survey appear, please take the time to tell us about your experience if you can.
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
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