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.

TMS570LS0432: FreeRTOS Port Stability for sprintf functions

Part Number: TMS570LS0432
Other Parts Discussed in Thread: HALCOGEN

I am working on evaluating the FreeRTOS port for the Hercules Launchpad evaluation board to see if it can be used for a Cubesat-like project.When transitioning from the default non-FreeRTOS HalCoGen Code to the Default FreeRTOS HalCoGen code, I'm observing difficult to diagnose issues with various symptoms (I'm happy to provide follow on descriptions of the symptoms I've observed to date.)

The simplest of these issues is contained in the following main program code encountered when using the sprintf-family of string formatting functions. I've confirmed this program runs on the non-FreeRTOS HalCoGen but I can make the issue present by toggling the `#if 1` in line 22 for the FreeRTOS HalCoGen. Since the issue presents as a system reset on line 19 and depends on code executed after line 22, I can only conclude that the issue stems from the creation of the compilation of the ELF file or perhaps result from the memory locations or restrictions on memory access related to the FreeRTOS port.

Any tips to get to the bottom of this issue would be much appreciated!

Also, any information you can provide on the history of FreeRTOS port and TI's current maintenance plan of this OS would go a long way to help me make sure Hercules+FreeRTOS is a good choice for my family of application(s).

#include "string.h"
#include "stdio.h"

int main(void) {

  char buffer[36];

  // Fixed Length sprintf
  sprintf(buffer, "abcdef");
  snprintf(buffer, 36, "abcdef");

  // strlen
  size_t string_length = strlen(buffer); // assert == 6

  // default int type
  {
  int number = -123;
  sprintf(buffer, "int: %d\n", number);      // Works
  snprintf(buffer, 36, "int: %d\n", number); // Does not work if following code block is enabled
  }

#if 0 // Toggle this to 1 to recreate the issue
  // default unsigned int type
  {
  unsigned int number = 123;
  sprintf(buffer, "unsigned: %u\n", number);
  snprintf(buffer, 36, "unsigned: %u\n", number);
  snprintf(buffer, 36, "unsigned: %4u\n", number);
  }

  // double precision
  {
  double number = 123.456;
  sprintf(buffer, "double: %lf\n", number);
  snprintf(buffer, 36, "double: %lf\n", number);
  snprintf(buffer, 36, "double: %4.4lf\n", number);
  }
#endif

  while(true){;}
}

  • Does increasing the stack size make the problem go away?

  • Hello Alex,

    The stack size of the HAL generated code is 0x300 for User. You can adjust the stack size from HALCOGEN GUI --> RAM

    I increased the stack size to 0x600, and didn't see the error.

  • Yes, this works for this example. Thanks!

    I'll take a closer look at the FreeRTOS memory configuration and see if insufficient stack space explains more of the platform instability I am observing.

    Is there any sort of documentation or primer about the memory configuration between HalCoGen and the FreeRTOSConfig.h - It's not clear as an end user when I can change FreeRTOS settings and when I have to regenerate HalCoGen settings.