msalau/rl78flash

Tool to program RL78 MCUs via serial bootloader

rl78flash's Issues

Windows Failed

I can flash the R5F100GC with the "Renesas Flash Programmer",but run rl78flash like:
rl78flash.exe -viva COM21 abc.mot
it always return:
failed
Initialization failed

it happens here:
rl78_send_cmd(fd, CMD_BAUD_RATE_SET, buf, 2);
int len = 0;
unsigned char data[3];
int rc = rl78_recv(fd, &data, &len, 3);
if (RESPONSE_OK != rc)
{
fprintf(stderr, "FAILED\n");
return rc;
}

what can i do to run it right?

Windows FAILED baud rate set

Hello, thanks for your code. But I have some problem with use.
I can flash R5F100MG with "Renesas Flash Programmer" by E1 hardware.
But I switch to “USB to DB9“ and “rl78flash” like:

rl78flash -b 500000 -vivavv com5 test-20220704.mot
rl78flash v0.7.0
                Open port: \\.\com5
Using communication mode 1
                Flush IO buffers
                Flush IO buffers
Send 1-byte data for setting mode
                send(1): 3A
                recv(1): 3A
Send "Set Baud Rate" command (baud=500000bps, voltage=3.3V)
                send(7): 01 03 9A 02 21 40 03
                recv(7): 01 03 9A 02 21 40 03
                recv(0):
FAILED baud rate set
Initialization failed
                Close port

By the way, I had install ch340 driver succeed and choose the right com number. Beacuse the DB9 port does not have VDD pin, so I had give the 5 volt by switching power supply to my device.

protocol C bug

There is a problem with protocol C, the data flash block size of RL78/G23 is 256 bytes, not 2048 bytes.

Read R5F100

Hi, thanks for you awesome tool.

I'm just one step prior to writing a RL78.

I would like to read and clone a RL78 to a blank rl78. Is there a tool anywhere? Glitching?

Entering programming mode

I have a blank R5F100PLAFB which I am struggling to get into programming mode. No matter what I do the rl78 does not respond. Is rl78flash supposed to automatically put the chip into programming mode? If not, how do you manage to do so? I have tried using a teensy 4.0 to for it into programming mode as specified in section 29.10 of the RL78/G13 user manual.

I am using this USB to Serial Breakout to communicate with the chip. I also have the 1kΩ pull up resistors for TOOL0 and RESET as well as the 1n4148 diodes as shown in hw/rl78s-hw.png. I have tried with and without the 0.47uF capacitor between REGC/VSS as well as the 0.1uF capacitors between VDD/VSS and VEDD/VESS. I have attempted using rl78flash in all 4 modes each with/without the invert reset parameter.

Misleading error message in case too big s-record file

If I try by mistake to program a microcontroller with an s-record file which is supposed for a different, bigger microcontroller, then the file will not fit in the memory.

In stdout I will see (-vv) "Read file D:\b\test.mot"
And in stderr "read failed"

The text "read failed" is misleading because it suggest that for some reason it was not possible to read the file while in reality the file was successfully read but was rejected.

Portiing uIP for YRBRX62NP

I try to porting the ethernet uIP on YRPBRX Board. And I use gcc and e²studio.

I change hardware setup but the system is freeze in function void _eth_fifoInit( ethfifo p[], pb_uint32_t status ) with not normal value on for loop.

I don't understant why I have this comportement.

Best regards.

r5f100fcafp (Renesas RL78/G13) 44pin

hi i need read this r5f100fcafp (Renesas RL78/G13) 44pin by your software but no connect can any tell me thanks

rl78s-hw.sch file can not open normaly.

I downloaded rl78s-hw.sch,but can not open normaly.
I had use Altium Designer (20.0.13) open it, it's nothing.

I had switch to Pads Logic(9.5),it said this:

Is there any problem with this sch file?

Initilization failed, error at rl78_recv

First of all, I installed this Linux driver: https://github.com/msalau/upd78f0730-driver, tested it and worked fine. I was able to read from and write to the serial correctly. The board I'm using is the YRPBRL78L12.

Then, I ran:

$ rl78flash -viva /dev/ttyUSB0 main.mot
FAILED
Initialization failed

The problem is at the function rl78_recv. The variables have this values:

in[0] = 0x0a
in[1] = 0x00
explen = 3;

and thus it returns RESPONSE_FORMAT_ERROR.

Do you know what is the problem here?

TOOL0 needs 1k pull-up

Hi,

First of all, this is a great tool Maksim. Good job 👍

I had some trouble getting it to work, which after some debugging turned out to be hardware issue. I'm using mode 3 (single wire UART).
The TOOL0/P40 signal needs to be pulled-up on the RL78 side - 1kOhm to VDD.
I'd indicate that on the hardware diagram image you included in the repo, so it's clearer.

Cheers

Error code when failed verification

One of the available commands is "-c", the verification.
If it is successful the return code is 0.
If it fails the return is code is 5.

The problem is that in case of failure there is always the same error code but actually there could be two different situations:

1. It is not possible to perform the verification because for example the microcontroller does not respond or something like this.
2. It is possible to perform the verification but the result is that the memory content does not match the expected hex file.

My proposition is that in case when verification is performed correctly but flash content doesn't match expectation the software should return a different error code than when verification could not be performed.

Not able to program (no response from microcontroller?)

I am not able to use rl78flash for programming a device with a 104jg microcontroller.

2.b:~> rl78flash -ivvvvd -m3 /dev/ttyS0
Open port: /dev/ttyS0
Using communication mode 3
Turn MCU's power on and press any key...
Send 1-byte data for setting mode
send(1): 3A
recv(1): 3A
Send "Set Baud Rate" command (baud=115200bps, voltage=3.3V)
send(7): 01 03 9A 00 20 43 03
recv(7): 01 03 9A 00 20 43 03
recv(0):
FAILED
Initialization failed
Close port

It looks like the microcontroller is not responding.
That's exactly the same thing that happened here:
#6
In that case the problem was unconneced reset.

So I verified my circuit that it is electrically correct and it is.
This is how the signals look like (reset and tool0):

And this is my circuit:

It's made after the rl78s-hw.png, but it has switches for selecting mode and power, an sp3232 chip and a 3v3 stabilizer. Powered from an usb cable.
I also have a second copy of this circuit made on a breadboard, without the switches. It's in mode 3. It doesn't work either.

It's also not the case of damaged microcontroller or device. I have access to several boards with a 104jg. None of them can be programmed with rl78flash but they all can be programmed with an E1 using the same cable.

So is the software doing something wrong? Like resetting incorrectly? timing? whatever?
Or maybe I'm using it wrong somehow?

Thanks in advance,
B

FT232RL causes 'Synchronization failed' error with -b 250000 or 500000 or 1000000 option (Windows)

I am facing following error while using FT232RL under Windows environment.

>rl78flash -m 2 -b 250000 -iav COM14 cotton_sketch.mot
FAILED
Synchronization failed

or

>rl78flash -m 4 -b 250000 -iav COM14 cotton_sketch.mot
FAILED
Synchronization failed

I debugged this problem for a while and I get an idea to solve it.

port_handle_t serial_open(const char *port)
{
    ...
    if (INVALID_HANDLE_VALUE == fd)
    {
        ...
    }
    else
    {
        DCB dcbSerialParams;
        GetCommState(fd, &dcbSerialParams);
        dcbSerialParams.BaudRate = CBR_115200;
        dcbSerialParams.ByteSize = 8;
        dcbSerialParams.StopBits = TWOSTOPBITS;
        dcbSerialParams.Parity = NOPARITY;
+      dcbSerialParams.fDtrControl = DTR_CONTROL_DISABLE;
+      dcbSerialParams.fRtsControl = RTS_CONTROL_DISABLE;
        SetCommState(fd, &dcbSerialParams);

        COMMTIMEOUTS timeouts;
        timeouts.ReadIntervalTimeout=50;
        timeouts.ReadTotalTimeoutConstant=50;
        timeouts.ReadTotalTimeoutMultiplier=10;
        timeouts.WriteTotalTimeoutConstant=0;
        timeouts.WriteTotalTimeoutMultiplier=0;
        SetCommTimeouts(fd, &timeouts);
        FlushFileBuffers(fd);
    }
    return fd;
}

The reason of the problem is FT232RL's (or its Windows dirver's) initial value of
fDtrControl and fRtsControl are as following and this makes RL78 reset
after SetCommState() is called in serial_set_baud().

dcbSerialParams.fDtrControl = DTR_CONTROL_ENABLE; // 'ENABLE' means DTR CONTROL line is set to 'Low'.
dcbSerialParams.fRtsControl = RTS_CONTROL_ENABLE; // 'ENABLE' means RTS CONTROL line is set to 'Low'.

int serial_set_baud(port_handle_t fd, int baud)
{
    DCB dcbSerialParams;
    GetCommState(fd, &dcbSerialParams);
    dcbSerialParams.BaudRate = baud;
    return SetCommState(fd, &dcbSerialParams) != 0 ? 0 : -1;
}

On the other hand, CP2102's (or its Windows dirver's) initial value of
fDtrControl and fRtsControl are as following and this makes no problem.

dcbSerialParams.fDtrControl = DTR_CONTROL_DISABLE; // 'DISABLE' means DTR CONTROL line is set to 'High'.
dcbSerialParams.fRtsControl = RTS_CONTROL_DISABLE; // 'DISABLE' means RTS CONTROL line is set to 'High'.

Best Regards,

Fail on empty line of s-record.

Some tools produce s-record (or hex) files which have an additonal empty line(s) at the end.
rl78flash will not accept such otherwise perfectly valid file.

It makes much more sense to accept these files than having to edit each file every time a software is released.
Empty lines can be safely ignored.

I am dealing with it by skiping the line if first character is '\r' or '\n':
in srec.c:
if ('S' != line[0])
{
if ('\r' == line[0] || '\n' == line[0])
{
break;
}
fprintf(stderr, "File format error (\"%s\")\n", line);
rc = SREC_FORMAT_ERROR;
break;
}
(I don't know why github is misformatting the indentation)

similarly for intel hex:
if (':' != line[0])
{
if ('\r' == line[0] || '\n' == line[0])
{
break;
}
fprintf(stderr, "File format error (\"%s\")\n", line);
rc = SREC_FORMAT_ERROR;
break;
}

(BTW, I wrote some questions in my pull request for intel hex support)

Return code is 0 even on failure

Tested on v0.6.0-initial-data-flash-support

The program returns -1 when there are problems with the parameters, file not specified, etc.
If everything is Ok then the return value is 0.

But if there is a problem during the programming - the microcontroller doesn't respond, the file can't be decoded, etc. then the return value is still 0.
It only writes a message to stderr and leaves the do loop by a break.

It could be solving by not only leaving the loop but also remembering the return value in a variable.

So if I call rl78flash from an external program, it will not know if it was successful or not which is problematic. The only way my probgram can know if it was successful or not is to also check if there are any bytesd on stderr which is not a good thing.

(a nice thing to have would be a different value for each problem)

I will edit the code for myself so that I am able to use it.

Edited to add:
I edited main.c to be like this:
main.c.txt
I will also edit main_g10.c similarly

Data flash not programmed

I have noticed that only the code flash is erased, programmed and verified.
The data flash is not.

I looked into rl78.c and I saw things like this:

int rl78_program(port_handle_t fd, void *code, unsigned int code_size, void *data, unsigned int data_size)
{
// Suppress "unused variable" warnings
(void)data;
(void)data_size;

which suggests that this is a feature that has been skipped on purpose, for later.
I this true?

Do you have plans to implement this?
Or maybe for some reason it was not possible to implement?

It is important for me to have this working.
I want not to need E1 programmers any more.
And the devices we are programming also need the data flash to be programmed.

If you are not planning to implement this then I might consider making a fix myself.
But I'm not familiar with your code so I would not be very effective.

Doesn't compile on RaspberryPi

There's a warning:

pi@raspberrypi:~/rl78flash $ make
cc -O2 -Wall -Wextra -Werror -c -o src/rl78.o src/rl78.c
cc -O2 -Wall -Wextra -Werror -c -o src/main.o src/main.c
src/main.c: In function 'main':
src/main.c:106:35: error: comparison is always false due to limited range of data type [-Werror=type-limits]
|| MODE_MIN_VALUE > mode)
^
cc1: all warnings being treated as errors
make: *** [: src/main.o] Error 1

The mode settings on Windows and Linux do not work the same way.

My circuit want reset by invert DTR signal.

Command on Linux (Raspberry Pi):
$ ./rl78flash -viva -nm1 /dev/ttyUSB0 firmware.mot

But the command below can work as well.
$ ./rl78flash -viva -nm3 /dev/ttyUSB0 firmware.mot

Command on Windows:
$ ./rl78flash -viva -m1 COM1 firmware.mot

Why can't I use the mode command on Windows like in Linux?

RTS reset issue

Not sure whether this is a bug in rl78flash or in the upd78f0730 kernel driver.
When using RTS for reset, as with the YRPBRL78L12 board, the MCU is permanently reset, since idle level of the RTS line is 0V. When using the -r option, the MCU is only put into run mode for a very brief moment. By inserting a sleep(1) before closing the serial port, the MCU runs longer. When closing the port, the RTS line returns to idle level. I haven't found a stty option to change the idle level of the RTS line. Maybe this can be fixed by patching the kernel driver.

I propose the code not using DTR.

Thank you for the wonderful code.
I am allowed to refer to it.
However, DTR did not exist in UB232R which I have.

It is a problem that these codes must use DTR.

RESET is controlled by RTS.
DTR does not use it.
As for the following, only an adjusting point is.

It was able to write in G13 well by UB232R.

Bye

Email:[email protected]

..........
int rl78_reset_init(int fd, int baud, int mode, float voltage)
{
unsigned char r;
if (1 == mode)
{
r = SET_MODE_1WIRE_UART;
}
else if (2 == mode)
{
r = SET_MODE_2WIRE_UART;
}
else
{
fprintf(stderr, "Unsupported mode %i\n", mode);
return -1;
}
communication_mode = mode;
if (4 <= verbose_level)
{
printf("Using communication mode %u\n", communication_mode);
}

//H.Okoshi 2012.11.02   //Original
serial_set_rts(fd, 0);  //serial_set_dtr(fd, 0);      /* RESET -> 0 */
ioctl(fd, TIOCSBRK);    //serial_set_rts(fd, 0);      /* TOOL0 -> 0 */
usleep(3000);
serial_set_rts(fd, 1);  //serial_set_dtr(fd, 1);      /* RESET -> 1 */
usleep(10);
ioctl(fd, TIOCCBRK);    //serial_set_rts(fd, 1);      /* TOOL0 -> 1 */
usleep(1000);

....

int rl78_reset(int fd)
{
ioctl(fd, TIOCCBRK); //serial_set_rts(fd, 1); /* TOOL0 -> 1 /
serial_set_rts(fd, 0); //serial_set_dtr(fd, 0); / RESET -> 0 /
usleep(10000);
serial_set_rts(fd, 1); //serial_set_dtr(fd, 1); / RESET -> 1 */
return 0;
}

protocol C bug

There is a problem with protocol C, the data flash block size of RL78/G23 is 256 bytes, not 2048 bytes.

Input file matching full data flash size is rejected

Hello! I tried to use rl78flash to send a 16kB .srec file to an R5F102AAA micro, and rl78flash bailed with just an error "Read failed". I added some more debugging and found that srec_read() was failing because address + data_length equalled CODE_OFFSET + code_len, but the condition did not allow for the equals case. Is this because it was supposed to match the data segment instead in some cases?

Probably these checks should change to data_length - 1, since writing one byte is really only updating the byte at CODE_OFFSET, not it and the one after.