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.

Program crashes after executing swi

Other Parts Discussed in Thread: CC3200

Hello,

I am using CC3200 launchpad and TI RTOS Simplelink V 2.00.02.36. I have created 5 tasks statically. Among these 5 tasks 4 tasks have priority of 2 and other one has 3. All these tasks are running pretty well before I have introduced swi into my program. I have created swi dynamically as per below..

Swi_Handle swi0;

Swi_Params swiParams;
Swi_Params_init(&swiParams);
swiParams.priority = 2;
swiParams.trigger = 0;

swi0 = Swi_create(swi0Fxn, &swiParams, NULL);

Program run very well until one of task post swi. Swi routine also get executed without any error but after execution of swi routine get finished program exits abruptly at loader_exit() in exit.c and prints following data in console.

se: 0x20015dec.
Hwi stack size: 0x400.
R0 = 0x00000000 R8 = 0x00000020
R1 = 0x00000000 R9 = 0x200156fa
R2 = 0x20015c44 R10 = 0x200156a4
R3 = 0x80f44f47 R11 = 0x200156a0
R4 = 0x0000a0df R12 = 0x2000c8ee
R5 = 0x0000a0e7 SP(R13) = 0x20016170
R6 = 0x00000004 LR(R14) = 0x2000e38f
R7 = 0x00000000 PC(R15) = 0x200101dc
PSR = 0x01000015
ICSR = 0x0400f003
MMFSR = 0x00
BFSR = 0x04
UFSR = 0x0000
HFSR = 0x40000000
DFSR = 0x0000000b
MMAR = 0xe000ed34
BFAR = 0xe000ed38
AFSR = 0x00000000
Terminating execution...

I think I'm missing something. What are probable reasons to cause this issue?

 

Edit : Uploaded config script of project. 4034.tcpEchoCC3200.cfg

 

Thanks,

Niral

  • I am having hard time to figuring out this issue. Can anyone help me?? Any inputs or suggestion is appreciated..
  • I am calling UART_write() from SWI routine. While debugging I have found that when program encounters call for UART_write() it shows Internal Error in task from which SWI is posted. Have a look at below screen capture..

    Any inputs or suggestion is appreciable.

    Thanks,

    Niral

  • Niral,

    In your ROV view, can you click on the “Hwi” module, and the “Module” tab and check the "hwiStackPeak" value?  

    I’m wondering if calling UART_write() from that Swi is causing the system stack (shared between Hwi and Swi) to overflow.

    Also, can you describe why are you posting a Swi to call UART_write(), versus just calling UART_write() from the task?

    Thanks,
    Scott

  • Hi Scott,

    Thank you for the response.

    can you click on the “Hwi” module, and the “Module” tab and check the "hwiStackPeak" value?  

    I have checked hwiStackPeak in ROV, hwiStackPeak is 868 while hwiStackSize is 1024.



    can you describe why are you posting a Swi to call UART_write(), versus just calling UART_write() from the task?

    Earlier I was calling UART_write() from task itself only but this was taking delay of about 2 second to receive at other end. My application can not bare such a delay. So I switched to Swi and Swi is taking very short amount of time. The task waits for certain event to be occur and once it happen it will post Swi, then Swi performs several operation and creates packet to be send. For packet creation I am using standard function of "string.h" and "stdio.h".

    Thanks,

    Niral

  • Hi Niral,

    Are you using the UART in callback (non-blocking) mode?

    Also, when using a task, did you try making that task higher priority (before trying with a Swi)?

    Thanks,
    Scott

  • Hi Scott,

    Scott Gary said:

    Are you using the UART in callback (non-blocking) mode?

    No, I am using blocking mode (UART_MODE_BLOCKING).

    Scott Gary said:

    when using a task, did you try making that task higher priority (before trying with a Swi)?

    Yes I tried increasing priority of task but didn't make big difference. What I want is when an event occurs, code that respond to that event has to execute without interrupting. I think increasing priority of task does not ensure that code will not be interrupted by any means.

    Thanks,

    Niral

  • Niral,

    Sorry for the slow reply.

    Software interrupts should be written to execute quickly and finish quickly.  They should not block CPU execution for extended periods of time.  If they block they will hold off all other Swis (at the same priority or lower), and Tasks, from running, and this may cause issues for any application.  For example, if you have a Swi running at the same or higher priority as the kernel’s Clock module Swi, then a blocking Swi will hold off the Clock module execution, and cause application timing issues.

    Can you try using callback mode instead for the UART?

    Regarding “I think increasing priority of task does not ensure that code will not be interrupted by any means”… Correct, increasing Task priority does not prevent interruption.  All it does is give the code higher priority versus code in other tasks, and the idle loop.  Running code as a Swi does not prevent interruption either – any higher priority Swi, or hardware interrupt (Hwi) will preempt a Swi.

    When your app is doing a UART transfer, *must* all other activity be prevented?  I wonder if there is an alternative that doesn’t hold off execution of other Swis.

    Thanks,
    Scott