It’s unfortunate that you can’t reproduce this problem because it makes your compiler unusable.

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

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

Hello, Thank you for reaching out to us! The M16C toolchain comes with a set of sample blink projects. The latest version of the toolchain can be downloaded from here: https://llvm-gcc-renesas.com/m16c-legacy-toolchains/ Although they are for other M16 devices (e.g. M3062),

Hello, Thank you for reaching out to us! Indeed, the toolchains source code is free to distribute since it is governed by a GPL licence. However, the toolchain installer itself is is free to download and use, only if you have

Hello, Thank you for reaching out to us. As we explained, these processors are thumb only, so using the .thumb directive is what you need. Because you are using the unified syntax (the same syntax for ARM and Thumb) you

fujimotoさん、こんにちは。NoMaYです。 ヒープ領域の大元はbspのsbrk.cで定義されているs_heap_areaという構造体のheap[BSP_CFG_HEAP_BYTES]という配列なのですが、正確には、この構造体/配列が配置されているアドレスに依存して、heap sizeで余分に必要とされるサイズが変化するのです。この構造体/配列が配置されているアドレスが4096バイト境界の少し手前から配置されていれば少ないサイズで済みますし、逆に、配置されているアドレスが4096バイト境界のずっと手前(言い換えると4096バイト境界の少し後)から配置されていると沢山の余分なサイズが必要になるのです。(なお、少し手前とか少し後とか、ざっくりした表現ですが、僅かに、数十バイト手前とか数十バイト後とか、そういう場合にどちらになるかは、すみません、ガッツリとnewlibのソースを見ないと分からないです。) ですので、もしfujimotoさんの手元のRX111のプログラムでその構造体/配列が配置されているアドレスが4096バイト境界の少し手前であればRX111でも0x400でmalloc(1)が成功しますし、逆に、もしfujimotoさんの手元のRX71Mのプログラムでその構造体/配列が配置されているアドレスが4096バイト境界のずっと手前であればRX71Mでも0x400でmalloc(1)が失敗する、ということになる筈なのです。 実際、私の手元で作成したmalloc(1)の確認用の以下のプログラムでは、RX111でもRX71Mでもheap sizeが0x400ではmalloc(1)が失敗してしまいますし、RX111でもRX71Mでもheap sizeを0x1000にしておけばmalloc(1)は成功する、という挙動になりました。 #include “r_smc_entry.h” #include <stdlib.h> void main(void); volatile void *p = NULL; /* volatileは最適化の影響でコードが削除されるのを防ぐ為 */ void main(void) { p = malloc(1); for (;;) ; /* breakpoint設定用 */ }

fujimotoさん、こんにちは。NoMaYと申します。 スマートコンフィグレータ(というかbsp)のnewlibのmalloc処理(正確にはその内部で呼ばれるsbrk処理)に私は多少の縁がありましたので調べてみました。newlib内部に4096バイト境界を意識した処理があり、例えmalloc(1)としても、最悪1+4095バイトを確保しようとする可能性があるようです。(ざっくりとしたイメージとしての言い回しですけれども。) なので、newlibのmallocを使用する場合、最低でもbspのheap sizeは0x1000としておく必要があるということになりますね。 [追記] 逆に言うと、パソコン向けの4096バイト境界を意識した処理をRXマイコン対応に改善しないといけない、ということですね。

Hello, Thank you for reaching out to us! We investigated your request and sent it further to the team that provides support for e2studio. You will be contacted as soon as possible with an answer. Best Regards The GNU Tools

Hello, Thank you for reaching out to us! In general, you may link a GCC-RX generated library in a CC-RX C project. For most functions, the ABI is compatible between the two of them. Nonetheless, our recommendation is to recompile