TX_WAIT_FOREVER doesn't in debug

[GreenGuy]

I have a board design using STM32H743.

I am using:

STM32CubeIDE

Version: 1.13.2

Build: 18220_20230914_1601 (UTC)

running on:

OS Name Microsoft Windows 10 Enterprise
Version 10.0.19045 Build 19045
System Type x64-based PC

I am debugging an implementation of Azure RTOS based on Azure-H7 rev 3.1.0

In my code I have a thread that provides a debug port (UART) and waits for user input (Rx) as well as outputs information provided wherever there is need to update status (Tx). In the portion of the code that waits for user input, I have a semaphore that is set by the competition of HAL_UART_RxCpltCallback that sets the semaphore after which there is a routine that parses the user input. Since this is an ongoing process that never stops , it sits in a while(1) loop.

the code looks like this:

while (1)

{

tx_semaphore_get(&DebugInput, TX_WAIT_FOREVER);

cnt += 1;

//parse command

memcpy(input_string, DebugBuffer, sizeof(input_string));

}

I put the counter in the code to test if the memcpy() call gets called more than the number of times user input is given.

If I place a break point at the memcpy() call the execution falls to the break point without any user input. This mean that the TX_WAIT_FOEVER did not work. I also break point the callback in case there is an actual put on the semaphore and it never breaks. Also, when the code breaks immediately after the tx semaphore get, the threadX window does not indicate that the semaphore was ever put (count=0).

you will notice that I do not receive or keep that status from the tx_semaphore_get call. If I capture the status like this:

while (1)

{

status = tx_semaphore_get(&DebugInput, TX_WAIT_FOREVER);

cnt += 1;

//parse command

memcpy(input_string, DebugBuffer, sizeof(input_string));

}

then the break point at cnt += 1 is never hit with no user input.

Sounds like a debugger problem.

[GreenGuy]

I have been able to determine that the tx_semaphore get is returning prior to a semaphore being set due to an error: TX_WAIT_ERROR.

Research indicates that this status is returned when "A wait option other than TX_NO_WAIT was specified on a call from a non-thread."

This is hard to understand how this situation might be occurring since the put is only performed in one place, after the thread that uses it is instantiated. I set a break point where the put is and the put is always done while in the appropriate thread.

The first pass through the code, the put and get behave normally which is that the get waits for the put to occur.  However, subsequent passes through the code produce the 0x04 status error returned by the get which does not wait.  Also, if there is a put count greater than 0, the count is not reduced when the get is made, and subsequent puts increase the semaphore count.

What I am unable to figure out is why the semaphore is acting this way and what puts it into a state where it always returns 0x04 and does not wait, nor can I find a way to clear the condition.   

[GreenGuy]

Tracing the error, in  _txe_semaphore_get the code checks for

/* Is the call from an ISR or Initialization? */

where the error is returned because the test:

if (TX_THREAD_GET_SYSTEM_STATE() != ((ULONG) 0))

falls through to:

/* A non-thread is trying to suspend, return appropriate error code. */

status = TX_WAIT_ERROR;

The call comes from a thread created during an init function where the thread is created as

ret = tx_thread_create(&DebugXThread, "DebugX Thread", debugx_thread, 0, pointer, TX_MINIMUM_STACK,

DEBUGX_APP_THREAD_PRIORITY, DEBUGX_APP_THREAD_PRIORITY,

TX_NO_TIME_SLICE, TX_AUTO_START);

after which the semaphore is created.

The entry point for the thread is debugx_thread which is instantiated as

static VOID debugx_thread(ULONG thread_input)

In that function (thread) is a while(1) loop wherein the tx_semaphore_get() function is called.

I would expect his call to be within a thread and not an ISR or Initialization function.

Is this a bug?, or do I have to go one more level down and within the first thread and create a new thread?

[GreenGuy]

Oh my.  It looks like I left behind a cut and paste error from some previous code.

the static keyword in front of VOID on the line:

static VOID debugx_thread(ULONG thread_input)

IS WRONG!

Do Not understand what the impact is and how the static keyword lead to the tx_semaphore get behavior, so  removing the static keyword got rid of the 0x04 status error.

[GreenGuy]

I was in error on the fix.  The behavior is back.  I have no idea why.  The thread no longer has the static keyword in the call declaration.  The error is still occurring in the same manner.