AD535 | BIOS | Booting | Bootloader | C621 | C6211 | C6415 | C671 | C6711 | C6711DSK | C6713 | CCS | Chassaing | COFF | DAT | DM64 | DM642 | DMA | DSK671 | DSK6711 | EDM | EDMA | EMIF | Emulator | EVM | EVM620 | FFT | FIR | GPIO | Halting | HPI | HWI | IDK | JTAG | LDB | LDH | LDW | Linker | LMS | LOG_printf | Matlab | McBSP | MEM_alloc | MIPS | PCI | PCM3003 | Pipeline | Profiling | QDM | Reset | ROM | RTDX | Sampling | SDRAM | Stack | TEB | THS1206 | TMS320C621 | TMS320C6416 | TMS320C6711 | TMS320C6713 | UART | Vector Table | XBUS | XDS560

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. | +--------------------\ (----( )-------------------+ \_) ) / (_/

______________________________
New Code Sharing Section now Live on DSPRelated.com. Learn about the Reward Program for Contributors here.



(You need to be a member of c6x -- send a blank email to c6x-subscribe@yahoogroups.com )

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 hasn’t been completed. Consequently, a TSK switch will occur if a TSK finds a segment locked. The 2nd task can only proceed it’s 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 User’s 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ße 22 10245 Berlin Email: Germany www.DSPecialists.de --------------------------------------------------------------- DSPecialists Making the Impossible Work ! Meet us at Embedded Systems 2002 in Nuremberg, Germany

______________________________
New Code Sharing Section now Live on DSPRelated.com. Learn about the Reward Program for Contributors here.



(You need to be a member of c6x -- send a blank email to c6x-subscribe@yahoogroups.com )

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 hasn’t been completed. Consequently, a TSK switch will occur if a TSK finds a segment locked. The 2nd task can only proceed it’s 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 User’s 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ße 22 10245 Berlin Email: Germany www.DSPecialists.de --------------------------------------------------------------- DSPecialists Making the Impossible Work ! Meet us at Embedded Systems 2002 in Nuremberg, Germany

(You need to be a member of c6x -- send a blank email to c6x-subscribe@yahoogroups.com )