EmbDev.net

Forum: ARM programming with GCC/GNU tools GCC memcpy bug?


von A. S. (aleksazr)


Rate this post
useful
not useful
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.
1
    int size;
2
    int crc;
3
    char text[128];
4
5
        size = orcf("0:fpga.bin", buff);
6
//      if (size != 54664) BKPT;
7
8
        crc = crc32C(buff, size);
9
10
        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...

von (prx) A. K. (prx)


Rate this post
useful
not useful
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.

von A. S. (aleksazr)


Rate this post
useful
not useful
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.

von (prx) A. K. (prx)


Rate this post
useful
not useful
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

von A. S. (aleksazr)


Rate this post
useful
not useful
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...

von (prx) A. K. (prx)


Rate this post
useful
not useful
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.

von A. S. (aleksazr)


Rate this post
useful
not useful

von A. S. (aleksazr)


Rate this post
useful
not useful
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.

von A. S. (aleksazr)


Rate this post
useful
not useful
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...

Please log in before posting. Registration is free and takes only a minute.
Existing account
Do you have a Google/GoogleMail account? No registration required!
Log in with Google account
No account? Register here.