Task-class cast in callback method not working

Kernel
1

Hi,

I’m using a class method to execute as a task.

Logger.cpp:

#include "Logger.h"
#include <cstdio>
#include "stm32g4xx_nucleo.h"

void call_logger(void* pvParameter)
{
	Logger* logger{static_cast<Logger*>(pvParameter)};
	logger->RunTask();
    vTaskDelete (NULL);
}


Logger::Logger(xQueueHandle queue) : m_Queue{queue}
{
    xTaskCreate(call_logger, "Logger", configMINIMAL_STACK_SIZE, (void*)this, tskIDLE_PRIORITY, &m_handle);
	m_nCount = 123;
}

Logger::~Logger()
{
}

void Logger::RunTask()
{
	//log_payload_t payload;
	uint8_t* value{};
	printf("Logger activated\r\n");
	while (1)
	{
		if ((uxQueueMessagesWaiting(m_Queue) > 0) && xQueueReceive(m_Queue, value, 0))
		    printf("Log Queue Data %d\r\n", *value);
		else
			vTaskDelay(5);
	}
}

Logger.h:

#ifndef LOGGER_H_
#define LOGGER_H_

#include "cmsis_os.h"
#include "task.h"
#include "queue.h"

typedef struct log_payload_t
{
    uint8_t message[256];
} log_payload_t;


class Logger {
public:
	Logger(xQueueHandle queue);
	virtual ~Logger();

	void RunTask(void);

protected:
	xTaskHandle m_handle;
	xQueueHandle m_Queue;
	int m_nCount;
};

extern "C" void call_logger(void* pvParameter);

#endif /* LOGGER_H_ */

In principe this worked just fine, up to the addition of a queue and some class members. When I look at ‘this’ inside the constructor xTaskCreate, this looks fine.

At the end, when call_logger is called, the void pointer points to the same address as this. But, after casting, no class members are set correctly. It seems they all point to zero’s.

How can I fix this?

Thanks in advance.

Greetings,

ErX

2

I’m not seeing all your code, so the problem might be elsewhere. One big thought that comes to mind is that you can’t create the object as a local object in main, as many of the ports use the main functions stack to be the ISR stack after the scheduler starts, so variable there get broken.

A second thing to watch out for, but doesn’t seem to be the problem here, is conversion to and back from a void pointer. If you convert a derived class pointer directly to a void pointer, and then back to the base class, you might not get the right pointer, you need to first convert the derived class pointer to the base class pointer, and then to a void pointer.

3

You can also use data breakpoints to catch where those members are getting set to 0.

4

Hi,

first of all, thanks for your reactions.

The strangest part of this code is, it works perfectly well on an ESP32 using IDF.

But it is going wrong (like stated in my first message) using an STM32G4 and the STM32 IDE.

(I cannot find the data breakpoints in STM32 IDE…)

When I create the queue inside the Logger class, that pointer still exists after casting. The m_Handle is still lost, which is strange because it is instantiated in the constructor of the class using the xCreateTask method.

Thanks in advance.

Greetings,

ErX

5

Can you share your complete code?

6

I tested your Logger on a Zynq-700, but it didn’t show mentioned problem.

Now you are casting from Logger * to void * and vv.

I came up with this idea:


class Logger;

struct this_holder
{
    Logger *this_cpy;
};

class Logger {
public:
    this_holder holder;
    Logger(xQueueHandle queue);
    virtual ~Logger();
    ...
};

Logger::holder is a simple struct , holding a copy of the this pointer.
So in stead of passing a pointer this a Logger object, you pass a pointer to its Logger::holder.
Would that make a difference?

Or would it make a difference if Logger has no virtual members?

EDIT : I forgot to attach the complete code as I tested it. Here is is:

Logger.zip (1.7 KB)

7

Hi,

Removing the virtual methods in the class, does not solve the issue.

Using the ‘this_holder’ shifts the problem. The pointer to the ‘this_holder’ seems to make sense. But, looking at the pointer (this_cpy) to ‘this’ is pointing to NULL.

Maybe the STM32G4 in combination with FreeRTOS handles the stack differently compared to my ESP32 or your Zynq-700?!

Greetings,

ErX

8

Hi,

program is not that big (yet). The main looks like this:

int main(void)
{
  HAL_Init();
  SystemClock_Config();

  MX_FREERTOS_Init();


  xQueueHandle log_queue = xQueueCreate(10, sizeof(uint8_t));
  printf("Queue created\r\n");
  uint8_t* pInt = new uint8_t(10);
  xQueueSend(log_queue, pInt, 0);

  Logger logger(log_queue);
  printf("Logger created\r\n");

  /* Start scheduler */
  osKernelStart();
}
9

The logger object is allocated on main stack, which is reset by FreeRTOS when starting the scheduler for some MCUs like Cortex-M3/4/7 for exclusive use by ISRs. The object might or will get corrupted. There are already a number of related posts in the forum.
Try allocating it on heap (new) or make it (module) static or global and add e.g. a set-ter method for the queue handle.

10

Using the new command made it work!

Thanks.

11

To the people who didn’t get it immediately: the stack that is used in the function main() might be recycled: it will (often) be used as a stack for ISR’s, interrupt handlers.

In @ErX example, the Logger object on the stack got corrupted as soon as the first interrupts occurs.

Lesson to learn: within main() is OK to declare objects on the stack. But do no try to access them after the schedulers has been started, because the “main stack” will be re-used for other purposes.

Thanks for all contributing to solve this issue.