• State TI Thinks Resolved
  • Locked Locked
  • Replies 9 replies
  • Answers 3 answers
  • Subscribers 54 subscribers
  • Views 694 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

CCS: Problem with Address in "MessageQ_alloc" and "MessageQ_free"

Mohan K S
Intellectual 260 points

Other Parts Discussed in Thread: SYSBIOS

Tool/software: Code Composer Studio

Hii All,

I am working on messageQ communication between ARM to DSP. I am creating two tasks in DSP, in first task MessageQ_get is placed in while loop. In second task I have MessageQ_free, messageQ_alloc and MessageQ_put. Dsp load i am building with the CCS v6.

ARM code has one thread, inside the thread i have messageQ_get and messageQ_put and ARM load is building in linux terminal. 

I have declared messageQ variable as follow

#define MSGQ_ALLOC_SIZE   16

MessageQ_Msg aAllocBuf[MSGQ_ALLOC_SIZE];

NOTE: I have allocated a 512 bytes of heap for messages.

I have a buffer of 16 which is used to allocate, put and free the message. When I am trying to allocate for aAllocBuf [0] , aAllocBuf [1] and so till aAllocBuf [15] it is allocating with the same address  for all the indexes of a buffer. After four allocations, I am freeing the buffer and it is freeing the allocated memory for some random messages and DSP core0 is crashing by throwing an error as follow

[t=0x00000009:c397944e] ti.sysbios.heaps.HeapBuf: ERROR: line 297: assertion failure: Cannot call HeapBuf_free when no blocks have been allocated
ti.sysbios.heaps.HeapBuf: line 297: assertion failure: Cannot call HeapBuf_free when no blocks have been allocated
xdc.runtime.Error.raise: terminating execution 
 
 
I am attaching .rar of my CCS project and ARM .c file.
 
Kindly refer my CCS project and ARM .c file for more understanding.
 
I AM ATTACHING THE SCREENSHOT OF MY TWO RUNS..
 
 
 
 

 
 
DSP project n ARM .c file.rar    This is my CCS project for DSP and also it contains the .c file of ARM.
 

ccsv6

bios_6_41_01_36

ipc_3_36_01_11

xdctools_3_31_00_24_core

 TCI6638K2K platform

windows10

Thanks n Regards

Mohan

 
 
 
  • 0
    TI__Mastermind 27355 points

    Hello Mohan,

    Mohan K S said:
    I have a buffer of 16 which is used to allocate, put and free the message.

    Once messageQ_put is called, the caller loses ownership of the message and can no longer free or delete it. I suspect this is the reason for the error you are seeing. You can free the message after calling messageQ_get and receiving the message. 

    Regards,
    Sahin

  • 0 in reply to Sahin Okur
    Intellectual 260 points

    Hi Sahin,

    Thanks for your reply.

    Sahin

    Once messageQ_put is called, the caller loses ownership of the message and can no longer free or delete it. I suspect this is the reason for the error you are seeing. You can free the message after calling messageQ_get and receiving the message. 

    Does this means which core (either DSP or ARM) has messageQ_get they only need to do messageQ_free ..?

    My test bench is like below:-

    Do you see any issue or any missing step in the above test bench..?

        We are assuming that ARM get and put the Msg back with the same address by way we wrote our program. But we are not sure, ARM is going to take the same address which is allocated by the DSP during the alloc or he has the different address..?

        As per your comment whoever puts the MSG will lost the control on that msg. During our Msg exchange example since we are using same address to put back from the ARM, weather DSP can gain back the control & can it free that allocated memory for MSG..?

    Regards,

    Mohan.

     

  • 0 in reply to Mohan K S
    TI__Mastermind 27355 points

    Hi Mohan,

    IPC follows a threading model where there is a single reader and multiple writers. The single reader thread calls MessageQ_create(), MessageQ_get(), MessageQ_free(), and MessageQ_delete(). Writer threads call MessageQ_open(), MessageQ_alloc(), MessageQ_put(), and MessageQ_close().

    The "caller" I mentioned in my previous post refers to a single thread, which could be a Task, Swi, or Hwi on different cores or on the same core. 

    You will need to modify your system so that the thread calls messageQ_free after calling messageQ_get. 

    Regards,
    Sahin

  • 0 in reply to Sahin Okur
    Intellectual 260 points

    Hii Sahin,

    Thank you for your suggestions..

    I have a scenario like DSP should send a interrupt exactly at 1 millisec. I am measuring the time after every MessageQ_get in ARM side and I have a if condition as below after MessageQ_get in ARM side. I am giving the Delay of 148000 cycles i.e around 996 microsec  in DSP side.

    getsystime(&stCurrsubframeTime);

    ui32DiffTime = getsystime_diff(&gsPrevsubframeTime, &stCurrsubframeTime);
    if((1150 < ui32DiffTime) || (850 > ui32DiffTime))
    {
    printf("Timed diff Prev:%ld.%06ld Curr:%ld.%06ld Diff:%ld\n",gsPrevsubframeTime.l32sec,gsPrevsubframeTime.l32microsec
    ,stCurrsubframeTime.l32sec,stCurrsubframeTime.l32microsec,ui32DiffTime);
    }
    gsPrevsubframeTime.l32sec= stCurrsubframeTime.l32sec;
    gsPrevsubframeTime.l32microsec = stCurrsubframeTime.l32microsec;

     

    Actual problem is I am not getting the interrupt exactly at 1millisec, the time is randomly varying for each MessageQ_get in ARM side. I am attaching the log prints for the above if condition

    TIME OUTPUT LOG

    Time diff Prev:1525063669.775078 Curr:1525063669.776349 Diff:1271
    Time diff Prev:1525063669.776349 Curr:1525063669.777075 Diff:726
    counter: 10000
    counter: 20000
    counter: 30000
    counter: 40000
    counter: 50000
    Time diff Prev:1525063719.874996 Curr:1525063719.876363 Diff:1367
    Time diff Prev:1525063719.876363 Curr:1525063719.876992 Diff:629
    counter: 60000
    counter: 70000
    counter: 80000
    Time diff Prev:1525063748.304215 Curr:1525063748.308819 Diff:4604
    Time diff Prev:1525063748.308819 Curr:1525063748.309017 Diff:198
    Time diff Prev:1525063748.309017 Curr:1525063748.309210 Diff:193
    Time diff Prev:1525063748.309210 Curr:1525063748.309402 Diff:192
    Time diff Prev:1525063748.309402 Curr:1525063748.309593 Diff:191
    Time diff Prev:1525063748.309593 Curr:1525063748.310205 Diff:612
    counter: 90000
    Time diff Prev:1525063753.765080 Curr:1525063753.766648 Diff:1568
    Time diff Prev:1525063753.766648 Curr:1525063753.767081 Diff:433
    Time diff Prev:1525063754.185144 Curr:1525063754.187004 Diff:1860
    Time diff Prev:1525063754.187004 Curr:1525063754.187197 Diff:193
    Time diff Prev:1525063754.604212 Curr:1525063754.607368 Diff:3156
    Time diff Prev:1525063754.607368 Curr:1525063754.607562 Diff:194
    Time diff Prev:1525063754.607562 Curr:1525063754.607754 Diff:192
    Time diff Prev:1525063754.607754 Curr:1525063754.608210 Diff:456
    counter: 100000
    Time diff Prev:1525063766.365037 Curr:1525063766.366238 Diff:1201
    Time diff Prev:1525063766.366238 Curr:1525063766.367038 Diff:800
    Time diff Prev:1525063766.785100 Curr:1525063766.786573 Diff:1473
    Time diff Prev:1525063766.786573 Curr:1525063766.787099 Diff:526
    counter: 110000
    Time diff Prev:1525063779.805125 Curr:1525063779.806663 Diff:1538
    Time diff Prev:1525063779.806663 Curr:1525063779.807126 Diff:463
    counter: 120000
    Time diff Prev:1525063788.225471 Curr:1525063788.226623 Diff:1152
    Time diff Prev:1525063788.415050 Curr:1525063788.419152 Diff:4102
    Time diff Prev:1525063788.419152 Curr:1525063788.419347 Diff:195
    Time diff Prev:1525063788.419347 Curr:1525063788.419539 Diff:192
    Time diff Prev:1525063788.419539 Curr:1525063788.419730 Diff:191
    Time diff Prev:1525063788.419730 Curr:1525063788.420043 Diff:313
    counter: 130000
    Time diff Prev:1525063791.985124 Curr:1525063791.987187 Diff:2063
    Time diff Prev:1525063791.987187 Curr:1525063791.987382 Diff:195
    Time diff Prev:1525063791.987382 Curr:1525063791.988122 Diff:740
    Time diff Prev:1525063795.135115 Curr:1525063795.137725 Diff:2610
    Time diff Prev:1525063795.137725 Curr:1525063795.137919 Diff:194
    Time diff Prev:1525063795.137919 Curr:1525063795.138111 Diff:192
    counter: 140000
    Time diff Prev:1525063807.734220 Curr:1525063807.737374 Diff:3154
    Time diff Prev:1525063807.737374 Curr:1525063807.737723 Diff:349
    Time diff Prev:1525063807.737723 Curr:1525063807.738063 Diff:340
    Time diff Prev:1525063807.738063 Curr:1525063807.738403 Diff:340
    Time diff Prev:1525063807.738403 Curr:1525063807.739212 Diff:809
    counter: 150000
    counter: 160000
    Time diff Prev:1525063821.805992 Curr:1525063821.807557 Diff:1565
    Time diff Prev:1525063821.807557 Curr:1525063821.807991 Diff:434
    Time diff Prev:1525063822.225059 Curr:1525063822.227889 Diff:2830
    Time diff Prev:1525063822.227889 Curr:1525063822.228082 Diff:193
    Time diff Prev:1525063822.228082 Curr:1525063822.228271 Diff:189
    Time diff Prev:1525063822.228271 Curr:1525063822.229056 Diff:785
    Time diff Prev:1525063822.645126 Curr:1525063822.648228 Diff:3102
    Time diff Prev:1525063822.648228 Curr:1525063822.648421 Diff:193
    Time diff Prev:1525063822.648421 Curr:1525063822.648612 Diff:191
    Time diff Prev:1525063822.648612 Curr:1525063822.649122 Diff:510
    Time diff Prev:1525063823.695793 Curr:1525063823.697111 Diff:1318
    Time diff Prev:1525063823.697111 Curr:1525063823.697791 Diff:680
    Time diff Prev:1525063825.375059 Curr:1525063825.378449 Diff:3390
    Time diff Prev:1525063825.378449 Curr:1525063825.378642 Diff:193
    Time diff Prev:1525063825.378642 Curr:1525063825.378832 Diff:190
    Time diff Prev:1525063825.378832 Curr:1525063825.379048 Diff:216
    counter: 170000
    Time diff Prev:1525063831.675035 Curr:1525063831.676935 Diff:1900
    Time diff Prev:1525063831.676935 Curr:1525063831.677129 Diff:194
    Time diff Prev:1525063835.664223 Curr:1525063835.668140 Diff:3917
    Time diff Prev:1525063835.668140 Curr:1525063835.668373 Diff:233
    Time diff Prev:1525063835.668373 Curr:1525063835.668566 Diff:193
    Time diff Prev:1525063835.668566 Curr:1525063835.668761 Diff:195
    Time diff Prev:1525063835.668761 Curr:1525063835.669218 Diff:457
    Time diff Prev:1525063837.555036 Curr:1525063837.557713 Diff:2677
    Time diff Prev:1525063837.557713 Curr:1525063837.557906 Diff:193
    Time diff Prev:1525063837.557906 Curr:1525063837.558098 Diff:192
    Time diff Prev:1525063837.975101 Curr:1525063837.978079 Diff:2978
    Time diff Prev:1525063837.978079 Curr:1525063837.978271 Diff:192
    Time diff Prev:1525063837.978271 Curr:1525063837.978462 Diff:191
    Time diff Prev:1525063837.978462 Curr:1525063837.979100 Diff:638
    Time diff Prev:1525063839.024782 Curr:1525063839.026790 Diff:2008
    Time diff Prev:1525063839.026790 Curr:1525063839.026986 Diff:196
    Time diff Prev:1525063839.026986 Curr:1525063839.027782 Diff:796

    I have Question 

    Is this functionality(MessageQ) is not applicable for Time Critical Implementation....? 

    I am attaching my DSP CCS project .rar which includes ARM .c file

    DSP CCS project with ARM .c file.rar

    Thanks n Regards

    Mohan

  • 0 in reply to Mohan K S
    Intellectual 260 points

    Hi Sahin,

    I am waiting for your reply......

    Thanks n Regards

    Mohan

  • 0 in reply to Mohan K S
    TI__Mastermind 27355 points

    Hi Mohan,

    MessageQ is typically not ideal for time critical application when the ARM is running Linux.

    The variability you see is due to Linux running on the ARM core. MessageQ is a user space application which needs to call into kernel space and involves Linux context switch, process priority, and multiple copies during the delivery of a message. Each message may show different latency due to this.

    Regards,
    Sahin

  • 0 in reply to Sahin Okur
    Intellectual 260 points

    Hi Sahin,

    Thanks for your reply. Two further questions

    1) TI recommends Message Q for ARM<->DSP communication. We need a communication mechanism for ARM<->DSP for a time critical application. If Message Q cannot be used, what is the alternative?

    2) Since you mentioned that the delay is due to Linux, can we use one ARM core in non-OS mode to get the required performance?

    Regards,

    Mohan

  • 0 in reply to Mohan K S
    Intellectual 260 points

    Hi Sahin,

    I am waiting for your reply...

    Thanks n Regards,

    Mohan

  • 0 in reply to Mohan K S
    TI__Mastermind 27355 points

    K2K has Inter-Processor Interrupt Registers (IPCGR) that can be used to send interrupts from one core to another. Using these directly might result in better performance. Keep in mind IPCGRx registers are already represented by multiple drivers in the Linux kernel (keystone-dsp-gpio for sending interrupts and keystone-irq for receiving interrupts). The same are used by the keystone remoteproc driver for doing the vring notifications.

    Using non-OS/RTOS on one ARM core should be more deterministic than Linux. We have not done any tests with this scenario to confirm as this is not a supported use-case of IPC.

    Regards,
    Sahin