LoggerSM output binary file

Hello all,

I work with Nadim on this subject.

We have additionnal questions because we started to notice strange things.

In LoggerSM_getBinary on line 341 is a

fwrite(readPtr, numBytes, 1, LoggerSM_obj.outfile)

In our case numBytes is around 60200 bytes. ReadPtr value is good, it points at the right place in the MSMC shared memory.
The outfile is in the ucLinux file system which is in DDR3.

We added some code around the fwrite and we see that fwrite returns 0 and errno = 14 (EFAULT).

The strange thing is that the data we get in the binary file (much smaller than expected) is OK because we see the same binary words in the memory browser.

We are wondering if it's not related to the mapMem part of the initialization which we don't really understand well for now.

Do you have any ideas with these issues ?

Thank you,
Clement

What are all the parameter values for LoggerSM_run? e.g.physBaseAddr, etc.

Hello Todd,

The parameter are :

physAdrr :0x0C040000 (MSMC)

Size: 0x30000

numPartition: 1 (only one core is written logs)

partitionMask: 0xFFFFFFFF

filename: loggersm.bin

Hello,

We are still stuck with this problem even if we tried to solve it by ourselves.

So if someone can give us a hand please. The problem is that when retrieving the binary file, it can not be opened on System Analyzer (more exactly when we do an Open from binary in SA with the good debug session, and in  the records window there are no records found).

We explored the generated binary file and we've seen that data are correctly written and UIA header seems to be correct also. 

Two probable lead can be that:

     - there is a problem of compatibility with System Analyzer,

     - the UIA header is not written correctly (using fwrite on a uCLinux target can bring such problems)

If anyone has any idea to solve it, it would  be very helpful.

Thanks,

Nadim

Nadim,

Can you attach the binary file?

Todd

Todd,

I attach 2 output binary file.

In fact we run the same code for 2 different loggers (loggerSM and LoggerCircbuff) so we can make a comparison between the 2 files even if there are not written the same way (we can check the number of events, the type of events,...).

The first binary file corresponds to a loggerCircBuff use. It has been generated by launching System Analyzer before running the program. 

The other binary file corresponds to a loggerSM use.

The problem is that we can't open our loggerSM binary file in SA.

Nadim

3056.logger.zip

Can you confirm that you are using 1.04.00.06 on the target? It looks exactly like the issue that was fixed in the 1.04.00.06 release:

SDOCM00103804: LoggerSM_write2 is incorrect when writing binary data

I looked at the binary data for the LoggerSM binary file. Here is a picture of the contents:

The event record circled in blue looks correct. The 0x02002008 decodes to seq #2 of 0x20 length and it's an event record. The yellow highlighted one has 0x03001808 which decodes to an event record seq #3 of length 0x18. The record is only 0x14 long. The 0x04001808 is the start of the next record. System Analyzer is reading length 0x18 for the yellow one. It then tries to get the next record, but it thinks the first word is 0x5982BFDD (circled in red). It gets confused and fails to process the file.

The fix for SDOCM00103804 to went into 1.04.00.06 was to add the following bolded line into LoggerSM_write2 in the  packages\ti\uia\runtime\LoggerSM.c file.

        myWrPtr = fillInEventHdr((Bits32 *)LoggerSM_module->sharedObj->writePtr,
                      numBits8ToWrite, LoggerSM_module->serial++);
        *(myWrPtr++) = ((evt) & 0xffff0000) | mid;
        *(myWrPtr++) = a1;

If you have an ealier version, you can make this same change and rebuild or upgrade to 1.04.00.06.

Todd

Todd,

The UIA package version error is correct. In fact I work now on a new computer with CCS V6.0.0 but I didn't notice that the packages (UIA and SYS/BIOS) was not updated.

So I rebuilt my program with the new packages and then launched my application. When I look into the binary file generated I see that:

     - the previous issue you pointed concerning event length and wrong start of the next event is now solved (see binary file attach)

But when I try to load it on System analyzer I have the same result, I mean that no logs is shown on the logs view in SA (see screenshot attach to this post)

I attach the new binary file generated.

Nadim

1004.loggerSM_v2.zip

Hi Nadim,

It looks like you should have been able to see the Log events in System Analyzer.  I was able to make a simple LoggerSM test, save the data + pre-pended UIAPacket header to a binary file, and then open this binary file in System Analyzer under CCSv6.  I don't see anything obviously wrong with your binary data.

Could you post the .out and generated rta.xml and uia.xml (which you can find under the package/cfg directory) that you used to generate the binary data?  Then we can try to reproduce the problem.

Thanks,

    Janet

Hi Janet,

Please find attach the whole project (including rta.xml, uia.xml and .out).

Regards,

Nadim

3441.Logger_SM_simpleEvent.zip

Hi Clement,

I'm glad to hear you figured out the cause of the problem.  In your binary data, for the "source" in the UIAPacketHdr, you have 0, which tells System Analyzer the data is coming from core 0.  Could you try changing that to a 1 and see if that works?  Here is what you posted when I 'od -x' it:

    00a0 d800 0000 0100 0100 3280 ffff 0000

The field in red is the source.  I think the header should look like this, if you're running on core1:

    00a0 d800 0000 0100 0100 3280 ffff 0100

Thanks,

    Janet

Hi Janet,

Nadim will try that today and will get you posted about the results.

However in the LoggerSM.c linux source code the "senderAdrs" is set as the partition id so we're not surprised to the see field at 0.

Also Nadim created another post for the multicore case

If you could take a look that would be much appreciated.

Clement

Hi Janet,

I modified my binary file as you suggested by changing the "source" bit (0 to 1) in the UIAPacketHdr.

Then I connected my core 1 like what I was doing previously and this time when I do "Open from binary file" it WORKS (logs are shown).

It seems like LoggerSM expect the following relationship :

Core id 0 = partition 0
Core id 1 = partition 1 etc.

In our case we have
Core id 1 = partition 0 and that's why SendAdrs = 0.

Can you confirm ?

Thanks,

Nad

Here's maybe a better way to fix the the problem.  Since core1 is using partition 0 of the LoggerSM buffer in your case, you can create a custom configuration file that has the endpoint address of 0 for core 1.  To do this, when you open the binary file, check the "Custom UIA configuration" as shown below:

Then click on "Create UIA Config File".  You should see something like this come up:

Now right-click on the TMS320C66x_1 row, and select "edit the selected item".  Then change the endpoint address to 0.  I think you will then be able to display the data in the binary file without having to change the source address to 1.

Best regards,

    Janet

Hi Janet,

Thank you for your feedback.

I tried the solution you proposed using the UIA config file and putting the Endpoint value to 0. The test is OK, all my logs are in the logs view of System Analyzer.

Our initial issue is now solved. Thank you for your time spent helping us.

Now we are working on the multicore loggerSM as you have already given us an answer.

We consider this thread closed.

Best regards,

Nadim