LoggerSM Multicore

Nad L

Hello everybody,

Before explaining my problem, here are my tools:

DSP C6678 with CCS V.6 , uia v.1.4.0.06, xdc v.3.25.3.72, bios v.6.37.1.24.

I connect my target on CCS and then connect two cores (core 1 & 2). I have also 2 projects with the same main.c but different cfg.

On one cfg project, I put loggerSM.partitionId = 0. On the other cfg, partitionId is 1.

numPartitions = 2, sharedMemSize = 0x2000 , baseAddress = 0x0C040000.

The section where is located the loggerSM is defined as NOLOAD section.
L1 and L2 cache disabled.

When I launched my programs at the same time (core grouped), it writes only one core events but not the other.

I mean that I may find sometimes at 0x0C040000 the loggerSM header + the core events and nothing at 0x0C041000 or all the contrary logs at 0x0C041000 and nothing at 0x0C040000.

Can someone help me please?

Nad

over 11 years ago

0 janet over 11 years ago

TI__Mastermind 22760 points

Hi Nadim,

I think what may be happening is that the auto_init_eff() running on one core is wiping out the LoggerSM module information that was initialized on the other core. The LoggerSM buffer is divided up into the number of partitions you have configured, and each core gets its own partition. At the beginning of each partition, there is some state information, containing among other things, the location of the buffer within the partition where the logs for that core are written. The LoggerSM module state is initialized in the function LoggerSM_setupBuffer(), which gets called after auto_init_elf(), but before main(). When auto_init_elf() runs, it initializes the entire LoggerSM buffer (all partitions) to 0. So if say core0 runs through auto_init_elf() after core1 has run through LoggerSM_setupBuffer(), the LoggerSM module state for core1 is wiped out.

LoggerSM was really designed for platforms like TI816x, where IPC is used. In this case, the M3s and DSP wait on Ipc_start() before initializing the LoggerSM partition. So with this synchronization in place, we didn't see this problem.

You can try setting a breakpoint at LoggerSM_setupBuffer() on core0, run core0 to LoggerSM_setupBuffer(), then run core1, and resume core0. If that fixes the problem, you will need to add some synchronization to your code.

Best regards,

Janet

0 Nad L over 11 years ago in reply to janet

Intellectual 255 points

Hi Janet,

It is our understanding that the boot sequence is like this (high level view):

a) beginning at c_int00
b) auto_init_elf
c) our synchronization function as Startup module First fcn
d) Module init including LoggerSM_setup_buffer
e) Main
f) IPC_start
g) BIOS_start

We tried this and it seems to work fine

Is it what you had in mind or is there a better way ?

We don't see how IPC_start can be of any help as it happens AFTER main.

Regards,

Nadim.

0 janet over 11 years ago in reply to Nad L

TI__Mastermind 22760 points

Yes, you are right. It was not the IPC_start() that was preventing the overwrite of the other cores' LoggerSM state. So, I'm not sure why this was working in the past on TI816x. Looking at some old map files, though, it looks like on the M3's, a different autoinit function is being used: _TI_auto_init instead of auto_init_elf.

It looks like there may be another work around you can try. According to the LoggerSM documentation, there is a function called LoggerSM_setSharedMemory() that you could call to initialize the shared memory used by LoggerSM. You would need to configure the LoggerSM.sharedMemorySize to 0 for this to work. Here is the API documentation:

    /*!
     * ======== setSharedMemory ========
     * Specify the shared memory to be used by LoggerSM
     *
     * This runtime API can be called once to initialize the shared memory
     * that the all LoggerSM instances use. This API can only be called
     * if '{@link #sharedMemorySize}' is set to zero. If
     * '{@link #sharedMemorySize}' is non-zero, the shared memory is
     * statically defined and initialized instead. Since the memory
     * is already defined, this API cannot change it.
     *
     * @param(sharedMemory) Base address of the shared memory to be used
     *                       by LoggerSM.
     * @param(sharedMemorySize) Size of the shared memory.
     *
     * @a(returns)
     * This function returns TRUE if successful. It returns FALSE if not.
     * The reasons for failure are either '{@link #sharedMemorySize}' is
     * non-zero or the API has been called multiple times.
     */
    @DirectCall
    Bool setSharedMemory(Ptr sharedMemory, Bits32 sharedMemorySize);

Could you try calling this function from main()?

Thanks,

Janet

0 Nad L over 11 years ago in reply to janet

Intellectual 255 points

Hi Janet,

I made a test with the solution you gave me using the LoggerSM_setSharedMemory() function in runtime to see if logs are correctly written in both partitions (when using 2 cores). For that, I put this function in my main() and I changed LoggerSM.sharedMemSize value to 0 as recommended.

When loading both my program on each core, the loggerSM header (with the first two events corresponding to task_ready) were previously written on only one partition.

But after running both, I can see that logs were correctly written on both partitions.

Your solution is correct and easier to set up contrary to the startup function.

So I consider that the basic problem concerning this post is now solved.
Thank you for your precious help and the time you spent solving my problem.

Maybe you can have a look to another issue I'm stucked with, concerning the overwrite. Here is the link : LoggerSM overwrite.

Thanks,

Nad

0 janet over 11 years ago in reply to Nad L

TI__Mastermind 22760 points

Hi Nadim,

I'm glad to hear that LoggerSM_setSharedMemory() solved the problem for you. It looks like someone else is already looking into the LoggerSM overwrite issue!

Best regards,

Janet

0 Clement FR over 11 years ago in reply to janet

Genius 4750 points

Hi Janet,

Thank you again for your help with Nadim.

I really think you could be helpful on this thread : LoggerSM overwrite.

Even though Todd replied, he seems already quite busy with many other threads.
Plus, you already have our context in mind.

If you have the time of course.

Best,

Clement

0 janet over 11 years ago in reply to Clement FR

TI__Mastermind 22760 points

Hi Clement and Nadim,

Sorry for not getting back to you sooner on this as I was out last Friday. It looks like you have solved the issue in the thread LoggerSM overwrite. It looks like a bug in LoggerSM, so I will file a report. Thanks for finding this.

Best regards,

Janet

Processors

Processors forum

LoggerSM Multicore