RTOS/TM4C1294NCPDT: Semaphore_pend() remains blocked after posted

Ryan Edwards

Part Number: TM4C1294NCPDT

Tool/software: TI-RTOS

I'm using a Launchpad TM4C1294 board to develop Modbus/TCP communication with the help of TI-RTOS and NDK. The application works very well at the beginning. The board is communicating well with my PC host interface and proper modbus formatted messages are being exchanged with my LabVIEW interface. The semaphore is being posted and pending works well. My code uses the NDK recv() function inside my user created ModbusServer() function. recv() is set to non-blocking.

Unfortunately after about 30 seconds of data transmission, the semaphore_pend() no longer seems to respond. I know that semaphore_post() is still working as I can see the count at 1 and the debugger still responds to breakpoints in the semaphore_post() contained function.

My debugging capability is evolving as I'm new to RTOS. I haven't noticed any unusual stack issues for the tasks in ROV. My execution graph works as expected up until the point of the lost semaphore_pend() at which time I can't graph any new events. I'm using an LED on the board to help me determine that the semaphore_pend() is blocking. When I halt the code after the Semaphore_pend() fails, I often find the code in Clock_workFuncDynamic() in the file "clock.c" with the exception when servicing clock0 which successfully calls MainLoopTrigger and appears to post the Semaphore.

I greatly any appreciate help debugging this issue. I've been working on this issue for a couple of days now and have reached the limit of my current debugging capability. I hope by reaching out in this forum that I can extend my knowledge and debug this issue. My software versions and screenshots are provided at the end of this post for your reference. Thank you for taking the time to review this request.

Sincerely,

Ryan

Compiler version TI v16.12.0.STS

NDK 2.25.0.09

CCS 7.0.0.00042

TI-RTOS for TivaC 2.16.01.14

EVENT SETUP:

CODE:

When Semaphore_pend() no longer seems to respond, the program appears to stay within Clock_workFuncDynamic() in the file "clock.c" except when servicing clock0 which successfully calls MainLoopTrigger.

over 6 years ago

0 Ryan Edwards over 6 years ago

Prodigy 225 points

I continue to learn more about this problem. In my search through the forums, I found a post on Debugging Queue and Semaphore that helped me focus on the timer controller. I changed the tick mode from "unnecessary timer ticks will be suppressed" to "timer will interrupt every period". I also updated the tick period to 1,000us and changed the clock0 period to 25 to maintain my desired 25ms semaphore servicing. This improved my performance dramatically. Since I'm new to RTOS, I'm not sure if I'm causing myself any future headache to this further down the line. Will this scale well? Can anyone offer advice? Is it better to have clock0 period to be 1 and the tick period at 25,000us?

0 Charles Tsai over 6 years ago in reply to Ryan Edwards

TI__Guru**** 159325 points

Hi Ryan,
What was the tick period you had originally before you changed to 1ms tick period. I guess you must have a very short tick period before, correct? In your clock0 function, the interval period is set to 1. This means the clock0 will fire off at the same rate as whatever your tick period was. If this is too short then the task may not finish before the next tick comes. I could image this was your original problem. With your latest setting of tick equal 1ms, I think it is reasonable if you are going to have your clock function at 25ms. I think this is better than 1us tick and the clock function interval at 25000us. With 1us tick you will have have generated 25000 interrupts before servicing the clock function. This is really hogging the system resources. I'm not a RTOS expert. Hopefully, our RTOS experts will provide additional comments.

0 Alan DeMars over 6 years ago in reply to Charles Tsai

TI__Mastermind 30830 points

The NDK stack assumes a 1ms Clock.tickPeriod so I wouldn't mess with that. There is a way to reconfigure the NDK stack to work with a different Clock.tickPeriod but I'm told it isn't easy.

Consequently, I recommend that you stick with a 1ms Clock.tickPeriod and configure your clock object period to be 25ms.

Alan

0 Ryan Edwards over 6 years ago in reply to Alan DeMars

Prodigy 225 points

Thank you Alan and Charles for your help and recommendations! Here is what I have in the cfg file now:

Clock.tickPeriod = 1000;
var clock2Params = new Clock.Params();
clock2Params.instance.name = "clock0";
clock2Params.startFlag = true;
clock2Params.period = 25;
clock2Params.arg = null;
Program.global.clock0 = Clock.create("&MainLoopTrigger", 1, clock2Params);

Previously my Clock.tickPeriod was set 25,000 and my clock2Params.period was 1. This original Clock.tickPeriod setting was the source of my problem and should be set to 1000 as you suggested. This seems to be working well now. I really appreciate your time and expertise to help me resolve this problem. Thank you!

Take care,

Ryan

Arm-based microcontrollers

Arm-based microcontrollers forum

RTOS/TM4C1294NCPDT: Semaphore_pend() remains blocked after posted