English
sprintf problem in GCC RX MCU
sprintf problem in GCC RX MCU
We are trying to use sprintf function in our code but are facing problems.
In certain cases, the program execution goes into Undefined Exception or Reserved Exception.
System Conditions:
Toolchain: GCC for Renesas RX 4.8.4.201902-SP1-GNURX-ELF
MCU: RX1115 – R5F51115ADFN
IDE: e2Studio v7.6.0
Library Settings:
The following code Executes properly without any issues.
char A[50] = {};
sprintf(A,”%s”,”HelloBoyos!!!”);
The following code throws an Undefined Exception when executed
char A[50] = {};
sprintf(A,”%s%s”,”Hello”,”Boyos!!!”);
The following code, when executed goes to the following non-existent address
char A[50] = {};
sprintf(A,”%d”,12);
Are we doing something wrong or is this a bug?
Any assistance will be really useful and greatly appreciated.
Thanks in Advance.
Vikram.
Thanks NoMaY, a larger stack solved the problem!
I wonder why the wizard selected such a small stack although this MCU has 96 kB RAM.
So the _ustack goes from 0x7FF down to 0x400 and the _istack from 0x3ff to 0x00? Is this right?
Another question: Is there any ‘best practice’ to implement a heap with gcc? I read in the wiki a special _sbrk function for RX (newlib), but it references the undefined function __set_heaptop.
I think it’s really hard to make the MCU work with gcc, heap and stack. So I really would apprecriate a walkthrough what I have to modify for the GCC-RX toolchain to get it work.
Bye,
Oliver
-
NoMaY-jp -
Hello Oliver,
Your understanding of the stack region and the stack growth is right.
For another question, I think that using e2 studio’s built-in RX Smart Configurator is good. Using the GUI of the RX Smart Configurator, you can select stack usage type (only I stack or both I/U stacks) and you can set stack size of I/U stacks and heap size.
(Until few year ago, the RX Smart Configurator couldn’t generate source code for GNURX, but recently it was improved to generate source code for GNURX.)
By the way, sbrk() is implemented in the generated src/smc_gen/r_bsp/mcu/all/sbrk.c and its implementation uses union variable ‘s_heap_area’ including ‘heap[BSP_CFG_HEAP_BYTES]’ member.
Unfortunately please note that heap size has to be larger than 4K bytes due to the current newlib implementation to avoid strange malloc() fail depending on the allocation address of the heap[BSP_CFG_HEAP_BYTES]. I think that this issue has to be improved for GNURX in the future. (I think that ‘4K bytes’ comes from the page size of the x86 processor’s MMU.)
Best regards,
NoMaY -
Hi NoMaY,
unfortunately the RX Smart Configurator option is grayed out if I select the RC62N MCU. And so I’m not able to define stack and heap sizes in the configurator.
I still don’t know which implementation of _sbrk is used as there’s no src/smc_gen folder in my project.
So I think I have to modify the linker script and the _sbrk function by myself to get a working heap.
The _sbrk function mentioned in the wiki seems to depend on some other functions like __set_heaptop, but I can’t find this function in the whole toolchain.
So in the end I still don’t know how to handle this with a RX62N/RX621 MCU.Thanks and bye,
Oliver -
NoMaY-jp -
Hello Oliver,
I’m sorry that I didn’t mind your target device. The followings are generated source code of sbrk.c and sbrk.h by RX Smart Configurator and these source code include sbrk() and related definitions/declarations/variables. I think that heap implementation of newlib doesn’t depend on target devices.
You don’t have to modify your linker script to use this sbrk() because the ‘s_heap_area’ variable used in this sbrk() isn’t a special variable but is a normal bss variable.
Best regards,
NoMaY -
Hello,
Indeed when using the printf function with an RX MCU which is having a small stack size (e.g 0x400 bytes) the stack pointer is wrapping around 0 (from the start of RAM – 0x0 to end of ROM 0xFFFFFFFF). This behavior is overwriting the vector table generating the errors. The fix this, you must increase the istack and ustack section sizes.
We are also in the process of updating the wiki page with the latest heap implementation found in the upgraded 3.1 newlib sources (the wiki referred to the older 2.7 version). Until then, we suggest using NoMay’s workaround: using RX Smart Configurator is another way of implementing a heap space, without modifying the linker script.
Best Regards,
The GNU Tools Team -
Hi,
hmm, I’m still confused as I can’t use the RX Smart Configurator because it is grayed out. If I open the Smart Configurator after the project has been created I get a blank page
And I can’t install any of the mentioned FIT modules in the RX driver package because the install option is grayed out too.Thanks and bye,
Oliver -
NoMaY-jp -
Hello Oliver,
> I can’t use the RX Smart Configurator because it is grayed out
The reason of this behavior is that the RX Smart Configurator doesn’t support old devices such as RX62N, RX63N, RX210, and so on. You can check the list of supported devices on the Renesas web site.
Best regards,
NoMaY -
OK, so it’s somehow harder to get this toolchain work with the RX62x. We have several active boards with this MCU and all I want to do is to check, if it is possible to switch over from the ancient HEW to e2studio with GCC.
In the moment it looks not too bad, although there are some pitfalls:– the stack sizes from the project wizard are too small to work with the stdio functions.
– the ‘_end’ label of the linker script marks the beginning of the heap.
– to reference this label the underscore must NOT be used
– to overwrite the “_sbrk” function it is also necessary to omit the underscore!Here’s my _sbrk function:
extern uint8_t end; // defined by the linker script
#define HEAP_MAX (64 * 1024) //64 KB
char *sbrk(int incr)
{
static uint8_t *heap_end = NULL;
uint8_t *prev_heap_end;if (heap_end == NULL)
heap_end = &end;prev_heap_end = heap_end;
if (heap_end + incr > &end + HEAP_MAX)
{
errno = ENOMEM;
return (void *)-1;
}heap_end += incr;
return (char *)prev_heap_end;
}Now I’m able to use stack and heap and all of this seems to work. Maybe the standard _sbrk implementation works, too (at least it references the _end variable of the linker script), but it does not check the maximum heap size.
Bye,
Oliver
Hi,
unfortunately, I have the same problem here, but with a different MCU and compiler. Using sprintf fires the “INT_Excep_UndefinedInst” exception handler when the code enters the line with sprintf. The array acces before works without problem and the array seems to be in the RAM section of the MCU.
MCU: RX62N on a YRDKRX62N with Segger jlink lite on board.
e2studio version: 7.8.0
GCC toolchain 8.3.0.202002-GNURX Windows
Everything compiles fine, the code skeleton is unmodified and created by the project wizard for this kind of MCU:
Pretty simple code:
#include <iodefine.h>
#include <stdio.h>
//Initialize global constructors
int main(void) {
char z[40];
z[0]=1;
z[1]=2;
z[2]=3;
sprintf(z,”%s”,”Hello Hello?”);
while(1)
{
// TODO: add application code here
}
return 0;
}
Linker script:
MEMORY
{
RAM : ORIGIN = 0x0, LENGTH = 98304
ROM : ORIGIN = 0xFFF80000, LENGTH = 524288
}
SECTIONS
{
.fvectors 0xFFFFFF80: AT(0xFFFFFF80)
{
KEEP(*(.fvectors))
} > ROM
.text 0xFFF80000: AT(0xFFF80000)
{
*(.text)
*(.text.*)
*(P)
etext = .;
} > ROM
.rvectors ALIGN(4):
{
_rvectors_start = .;
KEEP(*(.rvectors))
_rvectors_end = .;
} > ROM
.init :
{
KEEP(*(.init))
__preinit_array_start = .;
KEEP(*(.preinit_array))
__preinit_array_end = .;
__init_array_start = (. + 3) & ~ 3;
KEEP(*(.init_array))
KEEP(*(SORT(.init_array.*)))
__init_array_end = .;
__fini_array_start = .;
KEEP(*(.fini_array))
KEEP(*(SORT(.fini_array.*)))
__fini_array_end = .;
} > ROM
.fini :
{
KEEP(*(.fini))
} > ROM
.got :
{
*(.got)
*(.got.plt)
} > ROM
.rodata :
{
*(.rodata)
*(.rodata.*)
*(C_1)
*(C_2)
*(C)
_erodata = .;
} > ROM
.eh_frame_hdr :
{
*(.eh_frame_hdr)
} > ROM
.eh_frame :
{
*(.eh_frame)
} > ROM
.jcr :
{
*(.jcr)
} > ROM
.tors :
{
__CTOR_LIST__ = .;
. = ALIGN(2);
___ctors = .;
*(.ctors)
___ctors_end = .;
__CTOR_END__ = .;
__DTOR_LIST__ = .;
___dtors = .;
*(.dtors)
___dtors_end = .;
__DTOR_END__ = .;
. = ALIGN(2);
_mdata = .;
} > ROM
.ustack 0x200: AT(0x200)
{
_ustack = .;
} > RAM
.istack 0x100: AT(0x100)
{
_istack = .;
} > RAM
.data 0x204: AT(_mdata)
{
_data = .;
*(.data)
*(.data.*)
*(D)
*(D_1)
*(D_2)
_edata = .;
} > RAM
.gcc_exc :
{
*(.gcc_exc)
} > RAM
.bss :
{
_bss = .;
*(.bss)
*(.bss.**)
*(COMMON)
*(B)
*(B_1)
*(B_2)
_ebss = .;
_end = .;
} > RAM
}
-
NoMaY-jp -
Hello,
I think that this problem is due to the stack overflow. Would you modify your linker script as follows:
.ustack 0x800: AT(0x800) ← Here!
{
_ustack = .;
} > RAM
.istack 0x400: AT(0x400) ← Here!
{
_istack = .;
} > RAM
.data 0x804: AT(_mdata) ← Here!
{Best regards,
NoMaY
Hi Vikram_FE, we’re looking into your issue and will reply as soon as we have an update.
Hello,
Thank you for reaching out to us!
Unfortunately, we were unable to reproduce the issue with a basic sample testcase.
Could you please send us a sample project in which the issue is reproducible in order to investigate? We encourage you to please open a private support ticket where you could attach the project.
__
Best regards,
The GNU Tools Team