STM32G030F6 / STM32G031F6 interoperability

[Luke Iliffe]

At the moment we are struggling to get hold of any STM32G030F6's but we can get hold of STM32G031F6 chips. I've done an CUBE generation in the same pinout as the STM32G030F6 project and compared between the two projects and it looks to me that as long as I don't use any mallocs which rely on sysmem.c i should be able to run the same program. I've checked core files, drivers, startup files and linker scripts.

Can anyone think of anything i might have missed or if this is a bad idea for any other reason.

Thanks

Luke

[TDK]

The G030 has a subset of the features of the G031. It should work just fine. I don't see any reason why malloc would need to be different.

(The reverse is not true, of course.)

[Luke Iliffe]

Thanks for the quick reply. The only reason I said about malloc is the difference in sysmem.c where the G030 uses the minimal set:

/**
 ******************************************************************************
 * @file      sysmem.c
 * @author    Auto-generated by STM32CubeIDE
 * @brief     STM32CubeIDE Minimal System Memory calls file
 *
 *            For more information about which c-functions
 *            need which of these lowlevel functions
 *            please consult the Newlib libc-manual
 ******************************************************************************
 * @attention
 *
 * <h2><center>&copy; Copyright (c) 2020 STMicroelectronics.
 * All rights reserved.</center></h2>
 *
 * This software component is licensed by ST under BSD 3-Clause license,
 * the "License"; You may not use this file except in compliance with the
 * License. You may obtain a copy of the License at:
 *                        opensource.org/licenses/BSD-3-Clause
 *
 ******************************************************************************
 */
 
/* Includes */
#include <errno.h>
#include <stdio.h>
 
/* Variables */
extern int errno;
register char * stack_ptr asm("sp");
 
/* Functions */
 
/**
 _sbrk
 Increase program data space. Malloc and related functions depend on this
**/
caddr_t _sbrk(int incr)
{
	extern char end asm("end");
	static char *heap_end;
	char *prev_heap_end;
 
	if (heap_end == 0)
		heap_end = &end;
 
	prev_heap_end = heap_end;
	if (heap_end + incr > stack_ptr)
	{
		errno = ENOMEM;
		return (caddr_t) -1;
	}
 
	heap_end += incr;
 
	return (caddr_t) prev_heap_end;
}

and the G031 seems to use a more advanced set:

/**
 ******************************************************************************
 * @file      sysmem.c
 * @author    Generated by STM32CubeIDE
 * @brief     STM32CubeIDE System Memory calls file
 *
 *            For more information about which C functions
 *            need which of these lowlevel functions
 *            please consult the newlib libc manual
 ******************************************************************************
 * @attention
 *
 * <h2><center>&copy; Copyright (c) 2020 STMicroelectronics.
 * All rights reserved.</center></h2>
 *
 * This software component is licensed by ST under BSD 3-Clause license,
 * the "License"; You may not use this file except in compliance with the
 * License. You may obtain a copy of the License at:
 *                        opensource.org/licenses/BSD-3-Clause
 *
 ******************************************************************************
 */
 
/* Includes */
#include <errno.h>
#include <stdint.h>
 
/**
 * Pointer to the current high watermark of the heap usage
 */
static uint8_t *__sbrk_heap_end = NULL;
 
/**
 * @brief _sbrk() allocates memory to the newlib heap and is used by malloc
 *        and others from the C library
 *
 * @verbatim
 * ############################################################################
 * #  .data  #  .bss  #       newlib heap       #          MSP stack          #
 * #         #        #                         # Reserved by _Min_Stack_Size #
 * ############################################################################
 * ^-- RAM start      ^-- _end                             _estack, RAM end --^
 * @endverbatim
 *
 * This implementation starts allocating at the '_end' linker symbol
 * The '_Min_Stack_Size' linker symbol reserves a memory for the MSP stack
 * The implementation considers '_estack' linker symbol to be RAM end
 * NOTE: If the MSP stack, at any point during execution, grows larger than the
 * reserved size, please increase the '_Min_Stack_Size'.
 *
 * @param incr Memory size
 * @return Pointer to allocated memory
 */
void *_sbrk(ptrdiff_t incr)
{
  extern uint8_t _end; /* Symbol defined in the linker script */
  extern uint8_t _estack; /* Symbol defined in the linker script */
  extern uint32_t _Min_Stack_Size; /* Symbol defined in the linker script */
  const uint32_t stack_limit = (uint32_t)&_estack - (uint32_t)&_Min_Stack_Size;
  const uint8_t *max_heap = (uint8_t *)stack_limit;
  uint8_t *prev_heap_end;
 
  /* Initalize heap end at first call */
  if (NULL == __sbrk_heap_end)
  {
    __sbrk_heap_end = &_end;
  }
 
  /* Protect heap from growing into the reserved MSP stack */
  if (__sbrk_heap_end + incr > max_heap)
  {
    errno = ENOMEM;
    return (void *)-1;
  }
 
  prev_heap_end = __sbrk_heap_end;
  __sbrk_heap_end += incr;
 
  return (void *)prev_heap_end;
}

Although this differece could easily be something else like version of CubeIDE used during the generation.

[TDK]

Thanks for pointing that out.

Seems like those functions do roughly the same thing but in different ways. I would imagine both of them to work well on either platform (G030 or G031). Probably just some internal difference in CubeMX generation, as you said.

Both rely on stack being immediately after the heap, which can cause problems if you want to locate them in different memory regions.