|
Hi all, I'm developing an app with a few tasks; one of them initializes some buffers in IDRAM and SDRAM using MEM_alloc during task initialisation, and then uses them for the whole application time. The problem is that another task tries to allocate a pointer but it seems that the memory is locked and there's a context switch, so the alloc never occurs. The choices look as follows: do I have to call MEM_free before trying to allocate memory from another task, or should I make permanent buffers global (I don't want to), or there's any different way to define those buffers? Texas docs aren't quite helpful. Thanks in advance ''~`` ( o o ) +-----------------.oooO--(_)--Oooo.-----------------+ | | | PABLO FRAILE | | .oooO | | ( ) Oooo. | +--------------------\ (----( )-------------------+ \_) ) / (_/ |
|
|
MEM_alloc arbitration
Started by ●January 28, 2002
Reply by ●January 29, 20022002-01-29
|
pablo fraile wrote: > Hi all, > I'm developing an app with a few tasks; one of them initializes some > buffers in IDRAM and SDRAM using MEM_alloc during task initialisation, and > then uses them for the whole application time. The problem is that another > task tries to allocate a pointer but it seems that the memory is locked and > there's a context switch, so the alloc never occurs. The choices look as > follows: do I have to call MEM_free before trying to allocate memory from > another task, or should I make permanent buffers global (I don't want to), > or there's any different way to define those buffers? Texas docs aren't > quite helpful. > Thanks in advance Pablo, As one major limitation, DSP/BIOS memory allocation APIs such as MEM_alloc cannot be called from within the context of a software or hardware interrupt. This limitation has been imposed in order to ensure that the real time deadlines of HWIs and SWIs will not be endangered by the non-deterministic nature of the MEM_alloc function. Thus, dynamic DSP/BIOS memory management is limited to TSK (task) or IDL (idle) threads and the init routine and cannot be used in HWI or SWI threads. However, if MEM_alloc is used at TSK level, the critical section (the allocation algorithm) of the function is protected by an internal mutex / semaphore. This lock prevents any other concurrent TSK(s) to re-enter MEM_alloc trying to allocate memory from the same segment whilst the first allocation hasnt been completed. Consequently, a TSK switch will occur if a TSK finds a segment locked. The 2nd task can only proceed its operation after the lock has been released (when the 1st TSK completes MEM_alloc). To me, it looks like something went wrong when allocating the memory (i.e. the internal semaphore is still set / the MEM_alloc function has not been completed). Make sure that you pass correct parameters (i.e. segid, size, alignment) to MEM_alloc. Moreover, you should always check the pointer returned (must be not NULL!). During development, you can also monitor the current segment usage status by calling MEM_stat. The function MEM_stat returns the number of MAUs used and the length of the largest contiguous block in this segment. Regards Phil PS: The info needed can be found in the following TI docs: TMS320 DSP/BIOS Users Guide (SPRU423) at http://www-s.ti.com/sc/psheets/spru423/spru423.pdf TMS320C6000 DSP/BIOS Application Programming Interface (API) Reference Guide (SPRU403D) at http://www-s.ti.com/sc/psheets/spru403d/spru403d.pdf --------------------------- Dipl.- Inf. Phil Alder Field Application Engineer DSPecialists GmbH Rotherstra 22 10245 Berlin Email: Germany www.DSPecialists.de --------------------------- DSPecialists Making the Impossible Work ! Meet us at Embedded Systems 2002 in Nuremberg, Germany |
|
|
Reply by ●January 29, 20022002-01-29
|
Thanks very much!! Your knowledge of DSP/BIOS is astonishing. Effectively,
I had a MEM_alloc/MEM_free in a remote function inside an SWI, so the other tasks couldn't access memory. I have corrected it and now everything's ok. Regards -----Mensaje original----- De: Phil Alder [mailto:] Enviado el: martes 29 de enero de 2002 10:06 Para: CC: Asunto: Re: [c6x] MEM_alloc arbitration pablo fraile wrote: > Hi all, > I'm developing an app with a few tasks; one of them initializes some > buffers in IDRAM and SDRAM using MEM_alloc during task initialisation, and > then uses them for the whole application time. The problem is that another > task tries to allocate a pointer but it seems that the memory is locked and > there's a context switch, so the alloc never occurs. The choices look as > follows: do I have to call MEM_free before trying to allocate memory from > another task, or should I make permanent buffers global (I don't want to), > or there's any different way to define those buffers? Texas docs aren't > quite helpful. > Thanks in advance Pablo, As one major limitation, DSP/BIOS memory allocation APIs such as MEM_alloc cannot be called from within the context of a software or hardware interrupt. This limitation has been imposed in order to ensure that the real time deadlines of HWIs and SWIs will not be endangered by the non-deterministic nature of the MEM_alloc function. Thus, dynamic DSP/BIOS memory management is limited to TSK (task) or IDL (idle) threads and the init routine and cannot be used in HWI or SWI threads. However, if MEM_alloc is used at TSK level, the critical section (the allocation algorithm) of the function is protected by an internal mutex / semaphore. This lock prevents any other concurrent TSK(s) to re-enter MEM_alloc trying to allocate memory from the same segment whilst the first allocation hasnt been completed. Consequently, a TSK switch will occur if a TSK finds a segment locked. The 2nd task can only proceed its operation after the lock has been released (when the 1st TSK completes MEM_alloc). To me, it looks like something went wrong when allocating the memory (i.e. the internal semaphore is still set / the MEM_alloc function has not been completed). Make sure that you pass correct parameters (i.e. segid, size, alignment) to MEM_alloc. Moreover, you should always check the pointer returned (must be not NULL!). During development, you can also monitor the current segment usage status by calling MEM_stat. The function MEM_stat returns the number of MAUs used and the length of the largest contiguous block in this segment. Regards Phil PS: The info needed can be found in the following TI docs: TMS320 DSP/BIOS Users Guide (SPRU423) at http://www-s.ti.com/sc/psheets/spru423/spru423.pdf TMS320C6000 DSP/BIOS Application Programming Interface (API) Reference Guide (SPRU403D) at http://www-s.ti.com/sc/psheets/spru403d/spru403d.pdf --------------------------- Dipl.- Inf. Phil Alder Field Application Engineer DSPecialists GmbH Rotherstra 22 10245 Berlin Email: Germany www.DSPecialists.de --------------------------- DSPecialists Making the Impossible Work ! Meet us at Embedded Systems 2002 in Nuremberg, Germany |
