GCC memcpy bug?

OP #2045751
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...
OP #2046613
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...
OP #2086452
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...

Reply

Please log in before posting.

or

Log in with Google account

Registration is free and takes only a minute.

Register now