Question:
I'm using dual core processor(BF609),
->I need to access variable in L2 memory at the same time for both cores.
->If CoreA is writing and CoreB try to access that memory at same time what will happen, if it is a problem how to fix it.
===============
Answer:
It is possible for the linker to build the images for both cores as a single overall logical program. In this scenario, the shared memory spaces of the two cores are common, so the two private spaces (the L1 memories of each core) are making reference to a single instance of code or data in the shared space. This model has been supported previously in VisualDSP++, and is generally referred to as the Single Application/Dual Core model, or sometimes as the "five project model", since it was constructed from a project group of five projects.
This approach suffers from a number of complications, however. As a model, it can work quite well, but when problems arise, it can be very difficult to understand what causes them, or how to fix them. These problems include:
- Although, logically, you are building a single program, from the linker's point of view, you are actually building five programs, with some complex cross-linking.
- This means that you can have the same symbol defined in Core 0, Core 1 and in your shared L2 or external memory, and all those definitions are different, and valid. Indeed, main() has to be defined in both cores. This not only violates common understanding of C programs, but it also makes it difficult to identify whether your application is using the correct definition.
- It is possible for symbols in shared locations to make references to symbols in private core space. This leads to complications if the same symbol has a valid, private definition in each core, because the cores have different address spaces, and the shared symbol cannot be linked against both addresses.
- Because of the order in which the linker resolves library references and definitions in other cores/memory spaces, it is more likely that the linker will pull in additional definitions from the libraries, than it is to make use of your definition in shared memory.
- No RTOS will support this model.
For these reasons, among others, we no longer recommend this approach in CrossCore Embedded Studio, and instead recommend that a separate application is built for each core separately. A small amount of shared memory is set aside to support MCAPI, and you can, with care, share code and data by using MCAPI to pass the addresses of definitions from one core to another. This model is simpler, but that is a virtue in this case. Our experience shows that this approach is considerably more reliable, predictable and comprehendable, and is therefore more conducive to delivering reliable applications to market sooner.
Please note that, regardless of which model you adopt, you will need to ensure that any data accesses are properly protected by mutexes, and any cacheing of shared space will require appropriate cache flushing and invalidation, all of which is an application-level issue.
Please refer the below given CCES help path:
CrossCore
Embedded Studio 2.5.0 > Blackfin Development Tools Documentation > C/C++ Compiler and Library Manual for Blackfin Processors > Multicore Programming Application Model.
This document was generated from the following discussion: access of global variables for multi cores