Writemsg() takes 99% +++

Uri,

The writemsg routine is the lowest-level function for sending communications to the host syste. For example, at the bottom of a printf call, writemsg will get called. Assuming you have a host PC connected via an emulator, the host PC sees the writemsg call take place (via a hidden breakpoint I've been told) and then the host goes and reads a buffer on the target storing the message, looks at it, does anything it needs to and then I think it will reply to the target DSP, which the DSP picks up with a read message.  All of the above happens over the JTAG emulator interface and will significantly slow down a program you are running.

See here for using LOG_printf as an alternative in BIOS applications.

Regards, Daniel

Hi,

I use only LOG_printf()... I also removed all breakpoints, close all views - memory,disassembly, locals, watches....  (only the CCS4 "Debug" Windows remains).

Nothing helps.....

Regards,

Uri

One more input....

I just looked at the ROM logs. I found a log class "LOG_system" with 133770 (!!!) messages, all messages (as far as I checked) are idfentical
"SEM: post _TSK_mutex (0xc0101374)"

I use only "trace" log class.... probably some TI's binary library?

Uri,

You can not disable LOG_system but in the .tcf file you can reduce the buffer size to 0.
Have you tried that? I guess that the LOG trace should still be functionnal even if LOG_system is set to a size of 0.

In any case you should debug a little bit further to see where a SEM object is used as mutex mecanism and which part of your SW is using this SEM object. Usually SEM is used for as MUTEX mecanism to prevent TSK blocking. It looks like that in your case something is making 2 or more TSK to switch very often which I guess is not the wanted behavior.

BR,
A.

Hi,

Couple of days ago, I tried to remove the log from the TCF, and to set its length to 0 (additional to other few tests I made with the configuration), there were no effect.

I'll check the task switching, but I don't have the BIOS source code.... so I can't track down the SEM usage.

Regards,

Uri

Hi all,

Anyone knows why some DSP/BIOS functions issues LOG messages??

For instance SEM_postBinary()

When I run long program, which uses certain DSP/BIOS (5_41_02_14) functions, it spends most of its time within writemsg() and readmsg() context !!!

Any idea?

Uri

Hi

Maybe I have the same problem when i use the ROV (DSP/BIOS 5.41 in CCS4) the profile my project.

ENV:  dm6467t + CCS4.1 + dm6467_h264dec_1_10_05_03_production + DSP/BIOS 5.41

I create a project, and then create a H264 decode  task in DSP/BIOS (only one task ecpect idle task in this project , and the H264decode use the dm6467_h264dec_1_10_05_03_production  code). When i use this project to decode the 264 raw file continuous  (without task switch), the project running OK; But when i use the TSK_sleep blocked the decode task, the decode task cannot run back. If i don't use the decode function , the task switch is ok.

I debug this project with ROV in ccs4. I found that the LOG_system moudle info have many message :SEM: post _TSK_mutex (0x8810f4fc) . Because i use the decode code in my task, and the decode code use the HDVICP,EDMA and so on. Maybe the between the dsp and other co-processor have switch there TSK very often (but i can not see the code in the decode lib from Ti), and I don't know how to suspend and restart their Mutex mecanism. When decode one frame I must blocking my decode task a few  interval.  how to finish this task switch ?

Thanks a lot for your help.