Sdram0 bank 0 overlapped allocation
I'm using a standard project with a generated LDF file.
Sdram memory partion is by default as following:
MEM_SDRAM0_BANK0 { TYPE(RAM) START(0x00000004) END(0x00ffffff) WIDTH(8) }
MEM_SDRAM0_BANK1 { TYPE(RAM) START(0x01000000) END(0x01ffffff) WIDTH(8) }
MEM_SDRAM0_BANK2 { TYPE(RAM) START(0x02000000) END(0x02ffffff) WIDTH(8) }
MEM_SDRAM0_BANK3 { TYPE(RAM) START(0x03000000) END(0x03ffffff) WIDTH(8) }
I've noticed a strange behavior when I allocate frame buffers in sdram0 bank0: section("sdram0") u8 sFrame0[FRAMESIZE];
First lines of the video frame0 have corrupted pixels. Further investigating the problem looking at memory allocation I noticed that sFrame0 is overlapped with other memory section as you can see from the attached image.
The overlapping section are in particular l1_data_cache_b, l1_code_cache, l1_data_cache_a and heap section (ldf_heap_lenght….).
I solved the problem forcing a different mapping of sdramo_bank 0:
MEM_SDRAM0_BANK0 { TYPE(RAM) START(0x00001000) END(0x00ffffff) WIDTH(8) }
However I would like understand why this Issue happens and where I am doing something wrong.
Note: I use BF548 and VDSP++ 5 update 10.
Regards,
Emanuele
bank0
framebuffer
sdram
overlapping
sdram0
allocation
Show More
Hi Emanuele,
Could you provide a copy of the LDF also, so that we can take a look at that - in case there are any settings that may affect the placement of those symbols.
Regards,
Craig.
Hi Craig,
Here is the LDF
Hi Emanuele,
I can explain the symbols, and their addresses but this does not explain the corruption you saw, unfortunately.
The LDF defines a number of "LDF symbols" that are generally only referenced in the LDF, but in some cases may be accessed outwith the LDF. To take some examples from your screenshot, the symbols "___l0", "___l2", "___l4", etc are defined in the LDF at the start of the 'sections' block, and are used to define the length of some memory reservations that are required for a silicon anomaly workaround (as explained in the LDF).
These symbols are all defined in this manner:
RESERVE(___wab0=MEMORY_END(MEM_L1_SCRATCH) - 75, ___l0 = 76)
Notice that ___l0 is set equal to 76, which is 0x4c in hex; the address that the symbol shows in the Blackfin Memory Window.
Similarly, you will see - further down the LDF - the following definition:
___l1_code_cache = 1;
This is the address that the symbol shows in the blackfin memory window. (Similarly, albeit more complex calculations, the ldf_heap_length, etc, are defined in the LDF, and the address they are shown at is actually their value as defined in the LDF).
These memory locations are never written to in reference to these symbols, their 'address' is their value, which is used for calculations/references elsewhere in the LDF/application.
So, these symbols are only ever accessed to request their address (for example, the cache ones are accessed as 'guard symbols'. If objects are mapped into the cache area during the link process their address is set to 0, otherwise it is set to 1. These symbols are then tested by the CPLB libraries during run time initialization, to determine whether the cache location has been allocated or not.
Likewise the address of the heap symbols is checked to determine the bounds of the heap by the libraries. Again, these locations should never be written to, as all that should ever be done is to read the address of the symbols.
So, as I said, this does not explain the corruption you saw, but I do not believe it would be related to these symbols being mapped there, and can assure you that no overlapping mapping of data/code is occurring.
Regards,
Craig.
Thanks Craig,
if this symbols are only ever accessed to request their address and are NOT supposed to be overwritten, I can't understand too why this locations are overwritten.
When I first load the app the frame buffer is cleaned (all zeros). After Video encoder, video decoder and PPIs initializations (before I start DMA dataflow) the frame buffer located in SDRAM0 becomes dirty.
The dirty area resides in the blanked region an so is not normally visible in the video. If you use the image viewer or the memory viewer you can notice the data corruption.
I made a new project and let it "almost" empty. The only this I do is call ADI dev library to init the ADVs. After this operation the frame buffer in sdram0_bank0 is dirty.
If it is not a linker/ldf issue this problem may be related to the ADI library (but even this looks very strange).
Can you try to reproduce the problem with BF548?
Regards,
Emanuele
Hi again,
you could use the hardware breakpoints to trap any write to the section of memory that is being corrupted, to help narrow down where the corruption is occurring.
If you are unable to locate the issue, would you be able to provide a copy of your basic application so we can try to reproduce the issue? If you prefer to provide your code through private support, you can contact us through the link below:
http://www.analog.com/processors/support
Please include a link to this thread when contacting private support.
Regards,
Craig.
This question has been assumed as answered either offline via email or with a multi-part answer. This question has now been closed out. If you have an inquiry related to this topic please post a new question in the applicable product forum.
Thank you,
EZ Admin
Please log in to reply.