Hi Team,
I have UART connection problem in R-Car-V4H MCU RL78/F13.
I can't receive the correct data when the MCU sends buffer data('a') via UART.
If your have a sample code, please provide it to me, thank you!
uint8_t tx_buf[] = {'a'}; void clock_sleep(long d) { while(d--); } void main(void) { R_MAIN_UserInit(); R_UART0_Start(); while (1) { R_UART0_Send(tx_buf, 1); clock_sleep(1000000); } } void R_MAIN_UserInit(void) { EI(); }
Thanks!
Louis,
Hi Louis, I had the same problem with another controller (RL78/G23). What helped me was to change the source clock of the peripheral to a different one. If this doesn't help, it would be interesting to see what signal the controller is sending. I recommend using an oscilloscope or logic analyser. If you observe the signal, I think Putty's interpretation is a framing error 0xFF, which results in an ASCII symbol ÿ. For an "a" that you are trying to send, the binary interpretation is 0110 0001 and would look like this in a time domain:
If the pattern generated looks correct on the output pin, the problem of misinterpretation is very likely.It would be very helpful if you could provide a representation of your output signal.I hope this helps
PC_Renesas
This is the problem with the source clock, we can show 'a' after modifying the baudrate.Thanks!Louis,
The baud rate (and the rest of serial settings: parity, stop bit etc) on Putty has to be the same with the baud rate on RL78 side.
Hi AZ [Renesas],
That's right, but when I set both Putty and the Code Generator baudrate to 9600 at the same time on the R-Car V4H MCU RL78/F13, I encounter the issue mentioned above.
To put it differently, even when the baudrate is set to 9600 in both Putty and the Code Generator, and all other configurations remain consistent, I still experience the issue.Thanks!Louis,