I'm running C++ code using the HAL on a STM32F030x8. If I perform a "new" and there is not enough heap left, rather than returning 0, it sits on a BKPT 0xAB in _ttywrch and hangs. This is not ideal. Any ideas ?

[S.Ma]

Speaking only to what I know, malloc/new/free dynamic heap allocation is to be avoided in embedded space due to the SRAM that always need to be optimized. "unions" with static memory allocation or temporary storate in the stack would be prefferable when possible.

[Tesla DeLorean]

In Keil perhaps implement the hosting on your target properly so it outputs whatever message it is trying to output to the terminal.

There aren't infinite resources in embedded, perhaps there is a throw/catch mechanism to handle this, or some kind of structure exception handler.

//****************************************************************************
// Hosting of stdio functionality through USART3
//****************************************************************************
 
/* Implementation of putchar (also used by printf function to output data)    */
int SendChar(int ch)                    /* Write character to Serial Port     */
{
  while(USART_GetFlagStatus(USART3, USART_FLAG_TXE) == RESET); // Wait for Empty
  USART_SendData(USART3, ch);
 
  return(ch);
}
 
//****************************************************************************
 
#include <rt_misc.h>
 
#pragma import(__use_no_semihosting_swi)
 
struct __FILE { int handle; /* Add whatever you need here */ };
FILE __stdout;
FILE __stdin;
 
int fputc(int ch, FILE *f) { return (SendChar(ch)); }
 
int ferror(FILE *f)
{
  /* Your implementation of ferror */
  return EOF;
}
 
void _ttywrch(int ch) { SendChar(ch); }
 
void _sys_exit(int return_code)
{
label:  goto label;  /* endless loop */
}
 
//****************************************************************************

[nrose]

You are right - it is trying to write an error message to an unimplemented character routine. I put in my own _ttywrch and I see the message "SIGABRT: Abnormal termination".

Presumably there is some kind of exception handler being triggered - any idea how I can defeat it ? I'll look at the rt_misc error handling functions.

[Bob S]

Unlike malloc(), new is never supposed to return zero/NULL/nullptr. It either returns the requested item, fully constructed or it throws an exception. UNLESS you use the "no throw" syntax for new :)

http://www.cplusplus.com/reference/new/operator%20new/

[nrose]

You are of course correct - I was fooled because other compilers I use do not do this, presumably because they are non-compliant..

The Keil/Arm compiler that St supplies (V5.06) does not recognize (std::nothrow), but buried deep in the manual I found "--force_new_nothrow".

This will probably solve the problem, otherwise I shall just have to write better code.

To me as an embedded guy, it seems that the WORST thing any code could do is to exit the application, as this is by definition the end of the world, whereas for a PC application it might be quite reasonable. Ah well.

[Bob S]

Or add a try/catch block around the new call. The C++ paradigm is that uncaught exceptions halt the program. So if you don't want that to happen make sure to catch them. Or enable the nullptr return and check for that. It all depends on how "C"-like you want your C++ code to look :)