CCS C Software and Maintenance Offers
FAQFAQ   FAQForum Help   FAQOfficial CCS Support   SearchSearch  RegisterRegister 

ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

CCS does not monitor this forum on a regular basis.

Please do not post bug reports on this forum. Send them to support@ccsinfo.com

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

 
Post new topic   Reply to topic    CCS Forum Index -> General CCS C Discussion
View previous topic :: View next topic  
Author Message
E_Blue



Joined: 13 Apr 2011
Posts: 403

View user's profile Send private message

How to keep the USB CDC connected while the processor stall?
PostPosted: Mon Jun 13, 2022 1:26 pm     Reply with quote

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



Joined: 24 Jun 2004
Posts: 1899

View user's profile Send private message

PostPosted: Mon Jun 13, 2022 1:31 pm     Reply with quote

Code:
#DEVICE WRITE_EEPROM=ASYNC


You'll have to juggle polling when the write is complete and then doing the next write, but this should allow you to continue to service the USB connection in a timely manner.
E_Blue



Joined: 13 Apr 2011
Posts: 403

View user's profile Send private message

PostPosted: Mon Jun 13, 2022 1:43 pm     Reply with quote

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



Joined: 24 Jun 2004
Posts: 1899

View user's profile Send private message

PostPosted: Mon Jun 13, 2022 2:28 pm     Reply with quote

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



Joined: 11 Mar 2010
Posts: 19195

View user's profile Send private message

PostPosted: Tue Jun 14, 2022 11:27 pm     Reply with quote

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



Joined: 01 Jul 2010
Posts: 9081
Location: Greensville,Ontario

View user's profile Send private message

PostPosted: Wed Jun 15, 2022 5:23 am     Reply with quote

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



Joined: 11 Mar 2010
Posts: 19195

View user's profile Send private message

PostPosted: Wed Jun 15, 2022 11:51 pm     Reply with quote

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



Joined: 13 Apr 2011
Posts: 403

View user's profile Send private message

PostPosted: Tue Jun 21, 2022 6:40 pm     Reply with quote

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.

Code:
 for(x=0;x<1024;x+=64)
{
    delay_us(3000);
    usb_task();
}



The USB is in polling mode, so it seems to work.

I tried this in 2 PC, one with W10 and one with W7.

The µC is a PIC18F67J50.

As far I know it deletes 1K Bytes at a time but writes 64.

I don't know how the CCS library handles this; I mean, if 1K is deleted it must save the whole block in RAM, change the bytes and write all again because the flash can't be overwritten so it must be deleted first and then must been written.

Do I'm understanding correctly?

I'm planing to send one line with 64 bytes(actually 128 + 2CRC) and the Windows App will wait until the PIC ask for the next line.
_________________
Electric Blue
Ttelmah



Joined: 11 Mar 2010
Posts: 19195

View user's profile Send private message

PostPosted: Tue Jun 21, 2022 11:28 pm     Reply with quote

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



Joined: 13 Apr 2011
Posts: 403

View user's profile Send private message

PostPosted: Thu Jun 23, 2022 11:40 pm     Reply with quote

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
Display posts from previous:   
Post new topic   Reply to topic    CCS Forum Index -> General CCS C Discussion All times are GMT - 6 Hours
Page 1 of 1

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum


Powered by phpBB © 2001, 2005 phpBB Group