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.

RTOS/TMDSIDK437X: unhandled ADP Stopped when I use UART_Printf() in SWI

Genius 5840 points
Part Number: TMDSIDK437X


Tool/software: TI-RTOS

Hello.

I'm using rtos_template_app_am437x_a9 project.

UART_Printf() runs properly in tasks in the project.

But when I create swi and execute UART_Ptrintf() in SWI, following error is displayed.

→CortexA9: Unhandled ADP_Stopped exception 0x801492A0

Are there any way to execute UART_Printf properly in SWI?

Regards,

U-SK

  • Hello,
    in general such slow functions as UART_Printf() should not be used in any interrupt routine.
    Good programming practice is to keep INT routines as fast as possible. A way for you to use UART_Printf() depending on some conditions checked inside SWI is to raise a flag in SWI routine and after that to check this flag in the Task. Depending on it you can invoke UART_Printf() then.

    BR

    Michail

  • Hi Michail,

    Thank you for your reply.
    I understand the solution to avoid exception error.

    Could you tell me concrete reason why UART_Printf() execution in SWI cause exception error ?
    Is executing other slow function which take many CPU cycles in SWI also possible to cause exception error?

    Regards,

    U-SK
  • Sorry, I accidentally pressed the verify answer button.
    Could you give me an answer about above question?
  • Hello,
    the reason for this exception is that UART_printf() calls UART_osalPendLock() which in turn invokes SemaphoreP_pend(). It can not be used in SWI context because of SWI scheduler which is disabled at that time (SWI_disable in RTOS).
    Hope this explains the situation occurring in your case.

    Michail

  • Hi Michail,

    Thank you for your reply.

    I understand that SemaphoreP_pend() included in UART_Printf disables SWI scheduler and can not be used in SWI.

    >the reason for this exception is that UART_printf() calls UART_osalPendLock() which in turn invokes SemaphoreP_pend().

    >It can not be used in SWI context because of SWI scheduler which is disabled at that time (SWI_disable in RTOS).

      ->Do you have any documents described about your above answer?

    Regards,

    U-SK

  • Hi,
    I just looked in the source code to figure out this.
    For the RTOS part you can refer to www.ti.com/.../spruex3t.pdf

    BR
    Michail
  • Hi Michail,

    Thank you for your reply.
    > because of SWI scheduler which is disabled at that time (SWI_disable in RTOS)

    I confirmed content of SemaphoreP_pend() includeing Semaphore_pend(), but I can't find any code which disables SWI scheduler.

    Where and by what code is SWI scheduler disabled ?
    I am a little confused...

    Regards,
    U-SK
  • Hello,

    when you're inside SWI routine all lower priority ints are disabled including SWI therefore scheduler is not working at this time.

    This code is in TI-RTOS and it is TI proprietary, so you will not find source code for it to see for yourself.

    In the document I referred to in my previous post SWI is explained in chapter 3.8.

    Michail

  • Hi Michail,

    Thank you for your reply.
    I understand the reason why swi is disabled.

    >when you're inside SWI routine all lower priority ints are disabled including SWI therefore scheduler is not working at this time.
    By the way, could you tell me the reason detail why SemaphoreP_pend() can't be used over above situation?
    Are there any documents or source code described about it?

    Regatds,
    U-SK
  • Semaphore_pend is used to wait for a semaphore. The timeout parameter allows the task to wait until a timeout, wait indefinitely, or not wait at all. In UART_printf is used WAIT_FOREVER as timeout parameter. In case Semaphore_pend() did not success it is blocking in loop of waiting for a resource but at SWI context no one can free this resource. That's why all waiting, sleeping, wait external event operations are PROHIBITED in interrupt context.

    Michail

  • Hi Michail,

    Sorry for rate reply.

    >but at SWI context no one can free this resource.
    Could you tell me the reason why it is impossible that Hwi preempts Swi and post this semaphore while Swi waiting for semaphore ?

    Is it also impossible that Swi waits for setting any flag by Hwi ?

    Regards,
    U-SK
  • Hello,
    TI-RTOS is not working that way internally. Here are references to documents which explain that. Especially look at table with allowed and prohibited ways of use Semaphore_Pend() in SWI context.

    dev.ti.com/.../Semaphore.html

    also this thread
    e2e.ti.com/.../592950

    Michail