• State Resolved
  • Locked Locked
  • Replies 5 replies
  • Subscribers 99 subscribers
  • Views 822 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.

Error allocating memory from within a TSK context while SWI & HWI are enabled.

Patrick Moore
Prodigy 70 points
Other Parts Discussed in Thread: DM3730

Hi Guys,

 

I've a small problem here and hopefully you can point me to where I'm going wrong.

 

First off the problem,   we have a DSP/Bios program running on a DM3730 which receives configurations from the ARM side.  The control interface runs within a TSK which runs at start up.   During the processing of the control messages the TSK will create a buffer with the following line:

 

bufferPtr = (genericBuffer_st *)MEM_calloc(DDR2, sizeof(genericBuffer_st), GENERIC_BUF_MEM_ALIGN);

 

however, if SWI and HWIs are running at that moment using   SWI_enable();  and  C64_enableIER (C64_EINT4);   I get the following error: Sys abort called with message '*** MEM lock NOT CALLED IN TSK CONTEXT',  but if they are not everything works fine.  Oddly, disabling the SWI and HWIs doesn't allow me to allocate the buffer.   I've been fighting with this for a while and I've seen some similar problems on the forums, but none that I can apply to this context.    

NB, there is no allocation or freeing within the software interrupts,  other allocations within the task behave correctly though these are via a C++ new call, rather than MEM_calloc.  MEM_alloc has also been tried without success.

 

 

Thanks in advance,  this has been utterly frustrating.

 

Paddy

  • 0
    TI__Mastermind 18320 points

    Paddy,

    This error also appeared recently at http://e2e.ti.com/support/embedded/f/355/p/143431/518775.aspx#518775 -- did you see that?

    BIOS registers a mutex with the runtime library to make printf() and other functions thread safe.   The mutex is implemented using a SEM semaphore.  Since it is not legal to call SEM_pend() from and ISR with a non-zero timeout, we have a run-time check to look for this.   Review your ISRs to see if you can find an offending call to printf() (or something similar).

    Dave

  • 0 in reply to David Friedland
    Prodigy 70 points

    Hi Dave,

     

    I'd seen that, but unfortunately it doesn't seem to be the case.   There are a couple of sprintf's within the tskCtrl process (see below),  but no mentions of any printf, MEM_alloc, MEM_calloc or other within the ISRs.  

     

    For more information, the interrupts within the system are structured roughly like this:

     

    McBSP[1-5][RX/TX] -> HWI_4,  within HWI_4 I then post a SWI depending on which flags have been set in TPCC_IPR.  These are the only interrupts within the system save:

     

    ,KNL_swi,0x87e2f0b4,Inactive,0,0,KNL_run,0x00000000,0x00000000,0x107f9de0

     

    There are two TSKs running (that are visible within ROV):

     

    ,tskCtrl,0x87e16e7c,Running,1,0,0,,0x87e14e70,8192,728

    ,TSK_idle,0x87e27fa0,Ready,0,0,0,,0x87e2e740,1024,488

     

     

    Now,  enabling the HWI but commenting out the contents makes no difference to the running of the system,  thus suggesting that HWI and SWI elements aren't the primary cause of the problem there,  which is rather weird.

     

    Within the  project's TCF file the only references to interrupts are:

    bios.HWI.instance("HWI_INT4").fxn = prog.extern("_SDMATxRx");

     

    bios.HWI.instance("HWI_INT4").interruptSelectNumber = 29;

    bios.HWI.instance("HWI_INT4").useDispatcher = 1;

     

    all the SWI handles are generated at start up.

     

    Any other suggestions?

     

    cheers,

     

    paddy

     

  • 0 in reply to Patrick Moore
    TI__Mastermind 18320 points

    Paddy,

    Yep, that's odd...

    There is not enough information here for me to come up with a better idea.  Is there any other TI or 3rd party software components (e.g., PSP, NDK) you are using here that may be calling RTS services?

    Also, you should be able to discern a root cause by setting a breakpoint on SYS_abort() and then doing a stack backtrace (using the stackframe pointer in B3) to see which function is actually causing the offense to occur.

    Dave

  • 0 in reply to David Friedland
    TI__Mastermind 18320 points

    Paddy,

    One additional note...

    If you haven't done so, you should read over the GateMutex Wiki page.  At the bottom of the page is more detail on how to do a stack backtrace.

    Dave

  • 0 in reply to David Friedland
    Prodigy 60 points

    Hi,

    I've been able to resolve Paddy's MEM_calloc() not returning problem. SWI_enable();  C64_enableIER (C64_EINT4); were being called from main(). This isn't allowed since bios_start() runs after returning from main(). I don't fully understand the consequences of calling SWI_enable() from main() but know that there's an internal SWI_enable count in DSP/BIOS and persume this may have become confused. If anyone has a clearer view on why SWI_enable() can't be called from main() please enlighten me.

    MEM_calloc still didn't return though when I fixed this problem. The system log however reported two memory allocation errors so I increased the size of the heap and MEM_calloc()  worked. I am confused though why MEM_calloc() did not return with an error code when the heap size was not large enough. Anyone seen this before or have any ideas?

    Derrick