Slow programming in VirtualBox session solved

[Thomas]

I am using the Tiny PIC Bootloader + to flash a PIC18F14k22. I am working in a Virtual Box windows session on my MAC. All is working fine, but I noticed that flashing the firmware took a fair amount of time (about 9 seconds for 3.5kB). I increased the bootloader speed to 38k4, but that did not help. So I measured the transfer (see attached images) and saw that there was an interbyte delay of 2ms even with the Interbyte Delay set to 0.
So I loaded the PC software in Visual Studio 2017 (that needed some changes to be able to build) and I was able to solve the extra delay!

At an Interbyte Delay of 0, I do a Serialblock write, so the chars are send per block of (in my case) 64bytes and not byte by byte:

for (i = 0; i < blockLength; i++)
{
    // Calculate checksum
    checkSum[0] = (byte)(checkSum[0] + memBlock[i]);

    // = s.write(chr(memBlock[i])) ?
    if (!checkVirtualPIC.Checked && (localdelay > 0)) // byte per byte only with a delay value
        serialPort.Write(memBlock, i, 1);
    textRawTransfert.AppendText(memBlock[i].ToString("X2") + ", ");
    //System.Threading.Thread.Sleep(1);
    //Task.Delay(TimeSpan.FromTicks((int)localdelay));
    //Thread.Sleep(TimeSpan.FromTicks( (int)(localdelay) ) );
    for ( int IntreByteDelayLoop = 0; IntreByteDelayLoop < localdelay; IntreByteDelayLoop++)
    {
    }

    if (checkShowTransfert.Checked)
        textMessages.AppendText(" " + memBlock[i].ToString("X2"));
}
if (!checkVirtualPIC.Checked && (localdelay == 0)) // Blockwrite when delay is 0  
    serialPort.Write(memBlock, 0, blockLength);

Now the programming is taken place in less than 2 seconds!
The change is only active at an interbyte value of zero.

Maybe it is an idea to implement the change in the mainbuilds.

[Anobium]

What was the baseline code version you started with?
What is checkVirtualPIC?
Why not just set the delay to 0?

[Thomas]

The baseline code was the newest, v0.12.5.
checkVirtualPIC was already part of that baseline, I did not added that (but is was not checked)

As I said, I tested it with delay = 0, but the problem is writing 64 times a single byte to the RS232 port. Thats why I added the Blockwrite when the delay = 0.:

if (!checkVirtualPIC.Checked && (localdelay == 0)) // Blockwrite when delay is 0
serialPort.Write(memBlock, 0, blockLength);

And I changed this:
if (!checkVirtualPIC.Checked && (localdelay > 0)) // byte per byte only with a delay value
serialPort.Write(memBlock, i, 1);

The rest of the code is just original.

On another computer without virtualbox, I have less delay, then it is not really needed.

[Anobium]

Can you upload the source? I will then compare and merge. Thnks

[Thomas]

Attached the changed file. For the fix only line 1199 and 1212/1213 are needed, the other 2 changes were needed to get the project to build in Visual Studio 2017.

[Anobium]

@Thomas

That change no longer calculates the CRC, and, you send the blocklength not the memBlock which means it will fail on larger page size chips

Can we look at the change a bit more? This may not be MAC issue only.

[Thomas]

I don't understand, the for-loop with the CRC calculation is still there, only in that same for-loop the single byte is not send to the PIC when the delay is 0, only that part is done after the loop (The memBlock array is send with blockLength number of bytes). I tested it and it is working very well so far; did you also do a test?

I know from early days projects, that it is always more efficient to send more bytes in one serialport call instead of a number of separate calls.

[Anobium]

I justed tested on a q43 and it does not work as the block needs to sent many memblocks to fill the page.

I can recommend another change and it should resolve. I can look Monday (18th Jan).

[Thomas]

OK, I will looking forward to it!

[Anobium]

I have added a new check box to the config tab 'Force Block Transfer', and, I have then added logic to update the CRC etc etc.

I also added the new checkbox to the ini.

Grab it from here: https://1drv.ms/u/s!Ajq6ysRMSaJvjCAoWXcpGNrRjK6Z?e=yfXRsq

If it works I will release.

[Thomas]

Yes with the block transfer checkbox checked, the programming goes without delay, so that is looking very good! I also tested some other combinations, but 1 combination is not working now: Block transfer unchecked and a delay of 0, now I get this message:

Uploading PROGMEM
Uploading program memory
      no answer
ERROR: Problem in uploading HEX file to device
Closed COM12 serial port

When a delay is set greater than 0, it is programming again.

But thanks for your solution so far!

[Anobium]

Good to hear.

What is the chip config? family and number? and chip type? I dont get that error with a 16F88.

[Thomas]

Chip is a PIC18F14K22, baudrate 38k4;

Debug-info in tool:

Delay = 0, no block transfer:

Checking device
send: C1
receive: 62, 43
Uploading program memory
send: 00, 00, 00, 40; A0, EF, 1F, F0, FF, FF, FF, FF, 1D, 52, 00, 00, 01, E1, 12, 00, FD, 0E, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, B8,

Here it stops.... so no receiving char is displayed
But my logic analyser on the serialport shows only this:

name type start_time duration data error
Async Serial data 5.19317922e-15 0.0002460625 0xC1
Async Serial [1] data 0.000257625 0.0002460625 b
Async Serial [1] data 0.00051775 0.0002460625 C
Async Serial data 0.0250401875 0.0002460625 0x00
Async Serial data 0.0253005625 0.0002460625 0x00
Async Serial data 0.0255609375 0.0002460625 0x00
Async Serial data 0.025821375 0.0002460625 0x40
Async Serial data 0.028467625 0.0002460625 0xB8

nothing more

When I set the delay to 1, I see this:
Checking device
send: C1
receive: 62, 43
Uploading program memory
send: 00, 00, 00, 40; A0, EF, 1F, F0, FF, FF, FF, FF, 1D, 52, 00, 00, 01, E1, 12, 00, FD, 0E, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, B8,
receive: 43,
and also the other blocks....

When I set the Block transfer active I see this:

Checking device
send: C1
receive: 62, 43
Uploading program memory
send: 00, 00, 00, 40; B8,
receive: 43,
send: 00, 00, 40, 40; 80,
receive: 43,
send: 00, 00, 80, 40; 1D,

and the other blocks.... Here it looks like the debuginfo is not displaying all the data, but the flashing is fast and correct (also seen with my logic analyser).

[Anobium]

Give this a test. https://1drv.ms/u/s!Ajq6ysRMSaJvjCWQlV1jfQOpmkG6?e=mB6Jmy

I have added an explicit block of code to get the bytes out.

[Thomas]

Yes, now it's working in all modes!

One minor thing: when block transfer is active, the debug-screen is not showing all send bytes:
Uploading program memory
send: 00, 00, 00, 40; B8,
receive: 43,
send: 00, 00, 40, 40; 80,
..... etc
In above sample, before the B8 and B0 all databytes are missing of the block.

[Anobium]

:-)

Try https://1drv.ms/u/s!Ajq6ysRMSaJvjCemdpHeL37IINBy?e=zOxEDc

This has the printing of the values. Retest.

[Thomas]

Yes, now the debugscreen is showing all bytes.

Thanks for updating the software, now it is also fast within my virtualbox session.

[Anobium]

Case closed? :-)

I will post a new installer tomorrow if you say the job is done.

[Thomas]

Yes job is done! Thanks for your time for the quick update;-)

[Anobium]

Pleasure.