WARP Project Forums - Wireless Open-Access Research Platform

You are not logged in.

#1 2007-Jun-20 14:03:12

jyhng
Member
Registered: 2007-Jan-25
Posts: 37

memcpy

Hi,

For our current design, we're using the function memcpy to write a bunch of data bytes provided by the user into the transmitter Shared Memory Write-Only ROM.  However, when we use this memcpy function, we sometimes encounter a situation in which it overwrites the first three bytes of a four byte group with the last byte.  For example, suppose we send the string 'repeat', what gets written into the ROM is 'eeeett' (since the first four group of bytes is 'repe' and it takes the last one, 'e', and overwrites 'rep' with 'e', and then for the next group of four, it overwrites 'a' with the last, 't'). 

This problem is repeatable, so re-downloading the bitstream will still produce the same result, for the same input string.  This doesn't occur all the time though, and longer strings can be written correctly.  Note that each address entry in the ROM is 32 bits (4 bytes), which may be contributing to the problem.

Offline

 

#2 2007-Jun-20 16:55:39

murphpo
Administrator
From: Mango Communications
Registered: 2006-Jul-03
Posts: 5159

Re: memcpy

It sounds like you're running into problems with byte-enables on the OPB. The shared memory extension for sysgen2opb doesn't support byte-enables (since the dual-port RAM block in sysgen has a single WE port for any size data bus). When the OPB is asked to write a single byte, it repeats that byte 4 times, then uses a 4-bit BE control signal to flag which byte should really be written. In the case of sysgen2opb, the last byte written this way will occupy all four bytes of each 32-bit word, just like you've observed.

Try reworking your code to memcpy (or write directly via pointers) values typecast as unsigned int, and restrict your memory access to 32-bit boundaries. This may trick the compiler into executing 32-bit writes, which work normally.

Offline

 

Board footer