Yes, I've written a bootloader for it in a distant past. Can you clarify what kind of trouble you are experiencing?

I've pointed people to srecord in the past here multiple times. It's indeed an excellent tool and SiLabs has nothing comparable that I'm aware of.

And I surely do not buy thousands of units.

Of course I have only heard one side of the story, but it sounds like SiLabs owes you an apology.

Are you saying you were banned from THIS forum for mentioning sourceforge?

Then they might as well ban this Silicon Labs Pathfinder as well.

I have been an active developer of the SDCC compiler that is hosted there. It's only that I don't find so much time for it lately.

Maarten

Are you saying you were banned from THIS forum for mentioning sourceforge?

Then they might as well ban this Silicon Labs Pathfinder as well.

I have been an active developer of the SDCC compiler that is hosted there. It's only that I don't find so much time for it lately.

Your topic is a bit long, if you ask me. Please try to be a bit more brief next time and place your extensive question in the body.

Further, there is another major difference:

MOV PSW,#00H

vs

MOV PSW,#08H

Try to find out what they mean and I'm sure you'll understand the difference.

If you have any more questions, feel free to ask.

Also, when I look at handleUsbOut1Int(void) there is:

if ((myUsbDevice.ep1out.remaining == 0) || (count != SLAB_USB_EP1OUT_MAX_PACKET_SIZE))
{
  ...
  xferComplete = true;
}

which then results in a call to the callback. Thus when a transfer is completed the callback is called and it is not waiting for the buffer to fill up. I do not see the bug.

Also, when I look at '''handleUsbOut1Int(void)''' there is:

if ((myUsbDevice.ep1out.remaining == 0) || (count != SLAB_USB_EP1OUT_MAX_PACKET_SIZE))
{
  ...
  xferComplete = true;
}

which then results in a call to the callback. Thus when a transfer is completed the callback is called and it is not waiting for the buffer to fill up. I do not see the bug.

AFAIK the handler need not send NAKs as it should not be called in the first place when the USB endpoint is not primed for reception. It is the task of the USB engine itself to send NAK if it is not ready for receiving.

Stalling the endpoint OTOH could be a good way to handle the buffer overflow.