RX72Nでシリアル通信を行っています。（スマートコンフィギュレータでビットレートを設定し、コード生成しています。）
ビットレートが115200までは問題なく動作しているのですが、230400bps、460800bpsになると115200bpsと同様にコード生成を行っているのですが、文字化けしてしまい、うまく動作しません。
こちら、解決方法はありますでしょうか。
チョコです。
RXは使ったことはありませんが、RL78では色々と通信を行っています。
おそらく、UARTで通信されようとしていると思います。通信速度を高くすると通信相手の通信速度との誤差が大きくなり、文字化けしていると考えられます。これに加えて、信号波形の鈍りが影響していることも考えられます。
先ずは、実際の信号波形を確認してみてください。（UART以外では、波形の鈍りが文字化けの原因となります。）
UARTが対応する調歩同期通信については、「サンプルプログラム等」の「UART番外編」
https://community-ja.renesas.com/cafe_rene/m/sample_program/308
も参考にしてください。
以上
別の投稿ではTXD自体が信号を出していないと書いてありましたが、信号が出力されるようになったということでしょうか？
ボード間を直接UARTでつなぐような場合、同じボードの場合なら信号波形が乱れてしまっていることが原因だと思います。ボード間通信をされているなら距離にも気をつけるようにしてください。UART直接だと信号線のインピーダンスが高いのでノイズが少しでも乗れば、信号は乱れます。トランシーバICを使用するなども必要になります。
PCでモニターしてるのでしょうか？
ハードの問題では？試しにテラタームかなんかで二つのｃｈをクロスケーブルで繋いで試してみたらどうでしょう？
NAKAのPCは115200まででした。図1図2
USBシリアル変換ケーブルを使ったら921600まで行けました。 内蔵ブリッジICはFTD232Lだったかな？
USBシリアル変換ケーブルとRL78/F15マイコンで試したら、115200はOK 230400は27文字 460800は14文字 921600は数文字以降で文字化けでした。誤差の関係？図3
図1
図2
図3
RX72Nを出力として、PC（USB-Serialを経由してteraterm）端末にデータを送信する形で挙動を見てみました。
80文字×10行を何度か送って、目視で文字化けしているかどうかを判定基準としました。
USB-Serialチップは、
FT234X(~3Mbps)
PL2303GC(~12Mbps)
の2種類。
bps PL2303GC FT234X
230,400 〇 〇
460,800 〇 〇
921,600 〇 〇
1,000,000 〇 〇
2,000,000 〇 〇
3.000,000 〇 〇
4,000,000 〇 ×
5,000,000 〇
6,000,000 〇
7,000,000 ×
〇：文字化けなし
×：文字化け
スマート・コンフィグレータが出力したコードには一切手を入れていません。
2,000,000(2Mbps)までは、ビットモジュレーションなし。（ビットレート誤差は最大1%台）
3,000,000(3Mbps)以降は、（ビットレート誤差が大きかったので）ビットモジュレーションを有効にしています。（スマート・コンフィグレータの設定上チェックを入れただけです。）
7Mbps以降も、RX72Nが出力する波形を見る限り問題ありませんでした。受信NGとなったのは、使用したUSB-Seria変換回路の問題です。
文字化けする系（誰が出力で誰が入力かなど）がどうなっているか判りませんが、回路がイマイチでも230,400bps程度で問題が出るとも思えないのですが。
上記レスですが、最後のメッセージにリプライしたのでNAKAさまのメッセージのリプライとなっていますが、kiojfvycjtxdさまのRX72Nでの文字化けに対するメッセージ（簡単な検証結果）です。
ちょっと思ったのが、RX72NのTX(0-3.3V, CMOS出力）からMAX232などを使い、-10,+10V（など）のいわゆるRS-232Cレベルに変換して、PC（PCのシリアルポート）で受信されていますでしょうか。
MAX232ですと、140kbps(max)となっているので、230,400bpsは通らないかもしれないと思いました。
「（TTLやCMOS受けの）0-3.3Vの信号を扱える、一般的なUSB-Serial変換回路であれば」230,400bps程度では、文字化けしないと思います。
tf様のに追記させてもらいます
シリアル通信において
・信号波形の劣化
・周波数の違い（ボードレートエラー）
がエラーの原因ですので単純にビットレートを上げるとそのどちらか、もしくは、その両方が原因でエラーになりかねないです。またマイコンの通信相手がUSBシリアル変換チップを使った場合も特定メーカーのものは特定のボーレートはぴったりのボードレートにならないとかエラーレートの範囲が狭かったりする。マイコン同士でもUARTペリフェラルのクロック周波数が違えば、ボードレートのエラーレートが高くなります。あと実装の問題で受信完了後のマイコン処理が追いつかなくて正しく受信データをバッファにセットできなくてエラーなどということも通信速度が上がれば起こり得ます。
同一基板上レベルの配線長で起こるエラーなら信号波形の劣化ではなくボードレートの論理的なエラーだと思います。UART(TTLやCMOSレベルの信号)のまま信号線路は伸ばせないので装置間を繋ぐような場合はtf様が書いている通りトランシーバICを通して繋ぐ必要があります。全二重通信でやりたいならRS232用として、その一つとしてMAX232が使えます。もっと長距離に対応したい場合はRS422トランシーバを使用することになります。ただ配線がTXとRXそれぞれが２つ信号線が必要なのと電圧ではなく、電流を積極的に流す信号ですので消費電力はRS232より多めになります。半二重でいいならRS485がおすすめ。
>7Mbps以降も、RX72Nが出力する波形を見る限り問題ありませんでした。受信NGとなったのは、使用したUSB-Seria変換回路の問題です。
UARTが対応している調歩同期通信では、データ信号そのものだけでビット同期とキャラクタ同期をとらないといけないので、波形が崩れていないなら、受信側での受信性能とボーレート誤差および、受信信号とサンプリング・クロックの位相ずれだけの問題です。基本的に受信側のハードウェアの性能の問題です。Mbpsは、あまり意味がない（実用的ではない）かと思います。
どちらかと言うと、RXの受信の方が気になります。
>・信号波形の劣化
>・周波数の違い（ボードレートエラー）
>がエラーの原因ですので
Yamamotoさんのコメントに追加させてもらいます。
MCU側のUARTが受信の場合、いかに早くスタート・ビットを検出できるかも問題です。MCU内蔵のUART は基本的にデジタル回路のみでクロックを生成しているので、ボーレートに対してどれだけ高速のクロックを使えるかに依存します。
ちなみに、受信信号の変化の間隔から受信した信号の通信速度を測定し、それに追従するようなUARTもあるようです。
また、場合によっては、送信側のストップ・ビットを2ビットにすることもボーレート誤差の対策になる可能性があります。