How to keep the USB CDC connected while the processor stall?

[E_Blue]

I'm trying to create a bootloader by using the USB CDC library without interrupts (Polling mode) https://www.ccsinfo.com/forum/viewtopic.php?t=59120

The problem is that the library in polling mode requires that usb_task should be called faster than a millisecond and the self writing process stalls the microcontroller around 2.8ms.

There's any workaround this or is simply not possible?
_________________
Electric Blue

[newguy]

[E_Blue]

Thanks for answer.

I think that instruction let the library loop to be interrupted when is writing too much data but the stall is inherent to the processor architecture.

In my PDF (39775c) page 103 says:

12. The CPU will stall for duration of the write for TIW
(see parameter D133A).

And this in assembler code and there's no loop there. You can see the code in page 104.

P. D.: The microcontroller is a PIC18F67J50.
_________________
Electric Blue

[newguy]

My mistake. I confused EEPROM for internal flash. Sorry.

[Ttelmah]

What you have to do is send to the PC a command to say the CDC
connection is 'stopped', then do the write, then send the command to
say the CDC is active again.
The USB bootloader does do this. Using the XON/XOFF handshaking.
When XOFF is sent, the master should stop trying to send data (so the
polling interval no longer matters).

[temtronic]

OK, I'm curious....

Does the bootloader write an entire 'block' or 'page' of data ? IE fill a big buffer with data ,then issues a 'write' command ?
I know it's more efficient to do it this way.
The program would have to know the size of 'page' of course.....

Jay

[Ttelmah]

It uses a 64byte buffer. Reasonably efficient, but not a block size on
many of the larger chips. However on some chips the block size is so
large, it'd be difficult to have a RAM buffer this big. On chips like the
18FxxK42, it is worth expanding to 128Bytes, which makes it
the erase block size. In things like the DsPIC's, the erase page jumps
up to 512 or 1024 bytes, and really it is not worth expanding the buffer
beyond 128 bytes.
The pause though is not as bad as the poster seems to think. The chips
with much larger blocks normally write in only a couple of mSec. He hasn't
said what his chip is?. The default size is the erase block size on chips like
the 4550, which is why it was chosen. These are the same chips that have
the slow flash write times.
Understand that the PIC's USB hardware will still send a NACK to a
poll from the processor (which is what happens every mSec normally),
it is only if data tries to be sent that there will be a problem. Hence with
the handshake stopping data, things are OK.

[E_Blue]

I made a silly program that "receives" 1024 bytes and get in to a loop that makes a 3mS pause(write time is 2.8mS) and calls usb_task(); 16 times.

[Ttelmah]

You need to distinguish 'changing', from 'writing'.
The bootloader only writes. It does not attempt to change.
Basically if a write is done to the start of an erase page, the page is
erased, and then the following writes fill up the page.
You would need to have a buffer, read, and then write back if you
wanted to change a byte in a page. The bootloader does not do this.

[E_Blue]

I understand the part that it need to erase the whole 1KB to write 64 bytes.

What I didn't know that the erase procedure is accomplished IF the first 64 bytes are about to be written.

I was thinking that the library will delete that 1KB page every time but now I know how the library behaves.
_________________
Electric Blue