I have two yagartos: binutils: 2.21 gcc: 4.5.2 newlib: 1.19.0 gdb: 7.2 (23.12.2010, mifi) NEW and binutils: 2.20.1 gcc: 4.5.1 newlib: 1.18.0 gdb: 7.1 (13.08.2010, mifi) OLD Unfortunately, I can't show all of my code, but I can try to explain the problem.
int size; int crc; char text; size = orcf("0:fpga.bin", buff); // if (size != 54664) BKPT; crc = crc32C(buff, size); ArgPrint(text, "%D", crc);
This piece of code causes malfunction. What is the malfunction? Well, I'm a bit tired now and honestly can't tell... What I can tell is that the new version works if I uncomment the IF line or if I add a space in ArgPrint's 2nd param, like this: "%D ". I've checked the return value inside orcf and its always 54664. I guess it has something to do with memory address. (I have 32MB of SDRAM, so stack corruption is not very likely) I've compared listings of OLD and NEW version. There are 3 diffs: 1. memcpy is completely different. My "compare files" prog shows every line as non-matching. 2. because NEW memcpy is larger, almost every address is changed a bit: 20004024: 2001acd8 .word 0x2001acd8 <- this addr changed 3. in one of the functions, R1 is replaced with R2. Everything else is THE SAME, therefore I believe it has something to do with memcpy. The sym files shows all addresses as equal, except those found after memcpy. As I said, I'm tired now to do further testings. This may have nothing to do with memcpy, after all...
Please get some sleep and then explain again. And take a minute of reasoning on what a reader could do with your post. Especially since there is no memcpy shown in your code, neither code nor usage.
I was hoping to see something like "Yes, I have a memcpy problem, too." I'll try to replace all references of memcpy to my_memcpy and see if that helps.
A diff between memcpy.c in newlib 1.18 and 1.19 does not show any significant differences, though a different compiler may produce different code anyway. BTW: Are you sure that memcpy of newlib is actually used in both cases? http://sourceware.org/cgi-bin/cvsweb.cgi/src/newlib/libc/string/memcpy.c.diff?cvsroot=src&r1=text&tr1=1.2&r2=text&tr2=1.3&f=u
memcpy is used, I can see it in the LSS file. However, I don't think anymore that there is a problem in memcpy. Its definitely address related. I've switched back to OLD compiler, and a similar thing happens. Currently, my prog prints 0xAA on LCD. (0xAA happens to be 32nd byte in some buffer) If I add two NOPs in my ASM startup file in a place those two NOPs are not even executed, LCD shows 0x00. Have no idea...
A. S. wrote: > Have no idea... If you do not want to wait for some poor soul shouting "me too", you have to bring up details on your usage of memcpy. Up to now there has been no useful information besides the versions of the programs used.
The problem was in Spartan 3A connected to EBI, together with SDRAM. There are 'rumors' that FPGA may glitch pins during or near-the-end of a configuration process. After moving the configuration function and stack to internal SRAM, the problem disappeared.
My bad, as always. No, the FPGA does not glitch the pins during or near-the-end of configuration. I had bad signal quality on RD and WR clocks. I had both ringing and induction. The FPGA received invalid RD clock and interfered with SDRAM data bus. When I've moved the code to internal RAM, the CPU didn't read external data bus - that is why it worked. After adding series resistors to clocks, everything works just fine. I can program the FPGA while executing the code from SDRAM with or without MMU. I've even used xapp058 source to program it with JTAG. Hopefully this thread didn't discourage anyone from using the EBI with the FPGA...