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.
Hello,
I'm working with the ethernet MAC from the AT91RM9200 controller. I'm able to get a interrupt if I receive a packets - with the code example from atmel.
The packets are stored from the storage address 0x20010000 (external sdram) - 8 buffers a 1536 bits. How can I protect this storage place for the ethernet buffers?
typedef struct _AT91S_TdDescriptor { unsigned int addr; unsigned int size; }AT91S_TdDescriptor, *AT91PS_TdDescriptor;
AT91PS_TdDescriptor tdList = (AT91PS_TdDescriptor)AT91C_EMAC_TDLIST_BASE;
(ptr must be word-aligned)
and here's the initialization of the buffers.
for (i = 0; i < NB_ETH_RX_PACKETS; ++i) { tdList[i].addr = ((unsigned int) (pRxPacket + (i * ETH_PACKET_SIZE))) & 0xFFFFFFFC; tdList[i].size = 0; }
There's no variable of the struct or anything else. The only thing I tell the MAC is the pointer for the received frames.
But is this code not realy unsafe? Is it possible to use malloc to ensure the storage place for the buffers?
Johannes
How can I protect this storage place for the ethernet buffers?
Protect it from what? What exactly is your reason for setting up this variable so vulnerably?
You'll want to read the tools' documentation more closely about features to place variables at user-defined addresses.
malloc() is most definitely not used to guarantee the location of a variable. It is for dynamically allocated variables, i.e. a variable whose size and location is determined during runtime. This is 100% different from your requirements.
You may tell the linker that it may not store any information within a memory segment. Then you can manually set pointers to point into the reserved memory area.
Or you may declare variables at absolute positions, and specifically place them in the RAM area you want.
But if you use malloc(), you are only guaranteed to receive a NULL pointer, or a pointer somewhere within the heap space. And the first returned pointer need not point to the first byte of the heap space - most often, the malloc(9 function adds a hidden memory block just before the returned address, for internal book keeping - i.e. to let free() know how large the block is, and how free() may find the previous or next consecutive memory block and check if they may be merged.