using Microchip USB bootloader and where to start the code

[Yves]

Hello all,

I have found a USB bootloader for the 18F2550 at microchip. When I flashed it with Pickit 3 I notice the USB bootloader started right at the beginning of the ram and also found the end address. Shall I indicate where to start my code just after where the boot loader end or the "Declare BootLoader = On" declaration will cleaverly do that automatically? if not what is the procedure to avoid over writing the bootloader? Thank you.

Regards,

Yves 

[TimB]

You need to decide on running what your going to do. Run the bootloader or the main code

Unfortunately the bootloader article I wrote is not available any more as it was all covered then there.

I cannot find any file on my PC maybe someone else will have an example

[Yves]

Thanks Tim,
I remember in the past the code had routine something like below:

Declare Bootloader = Off
PROTON_START_ADDRESS = 0x0f00    ;where to start

But that doesn't seem to work any more. It would be nice to get some guide line from Les on that matter.
I would think it would be a great addition to Positron to get some addition concerning USB bootloader.

Regards,

Yves 

[Yasin]

PROTON_START_ADDRESS = 0x0f00    ;where to start

As far as I know this command. Changed to "Copiler_Start_Address"

[trastikata]

Shall I indicate where to start my code just after where the boot loader end or the "Declare BootLoader = On" declaration will cleaverly do that automatically? if not what is the procedure to avoid over writing the bootloader? Thank you.

I normally set the Bootloaders to be erase protected by the fuse configuration - this usually causes waste of some free code space because you have to lock entire sectors to do this. I also protect the configuration sector itself because if overwritten (for example you change the FRQ divider) the bootloader will fail thus rendering the device inoperative. This is all done during  bootloader design phase - thus the protection fuses are set during bootloader flashing. Then I remove from the main program code the configuration code because it can not be programmed by the bootloader and will give an error - basically trying to erase and reprogram a locked sector.

Where your main code should start - depends on your bootloader. The bootloader should have a pointer to the main code start - the designer of the bootloader (if for mass use)  should have mentioned where the main code starts.   

[Yves]

Thanks but "Compiler_Start_Address" doesn't exist in the manual and creates an error during compilation.
I wish Les would be kind enough to what is the way to do this. looking at the hex files I can see where the bootloader start and where it end. Maybe it is not possible and that will be a bummer.

Cheers,

Yves

[top204]

Make sure you are running the latest compiler version, because "Declare Compiler_Start_Address" is recognised, and has been for a while now. It is not "Proton_Start_Address" anymore, because the compiler is not Proton.

I am not planning on adding it to the the manual because if inappropriately used, it can cause havok with a program's operation in very subtle ways and it is always the compiler that gets the blame. For example, if it is set too high an address etc...

I discussed it here a few weeks ago:
Proton_Start_Address

[Yasin]

https://protoncompiler.com/index.php/topic,370.msg2285.html#msg2285

Is there a mistake? Les reported the change here.


The explanation has arrived. 

[Yves]

Les,

Thank you for your reply. I will have a go and see if it works for me. I definitely keep my the Positron compiler's updated as much as possible.

Regards,

Yves

[Yves]

Hello all Picsters,

I had good success with Les "USB18com.bas" and adapting it to the 18F2550 chip. I have been using Microchip USB for bootloader and programed the USB18com.bas at Declare Compiler_Start_Address = 0x0f00 and managed to get data on com12  from adin0 at portA.0.
There though, one issue I cant find a way to avoid: is the requirement to poll by even sending an empty string to get the data on the com. below the snippets in question:

USBInit                                             ' Initialise USB
Repeat                                              ' \
  USBPoll                                         '   Wait for the USB interface to become attached
Until USB_tConnected = 1 Or USB_tConfigured = 1     ' /

Do                                                      ' Create an infinite loop
    Repeat                                          ' Wait for USB input
            USBIn 3, In_Buffer, Auto                    ' Poll the USB and Receive some data from endpoint 3
    Until Carry_Flag = 0                                ' Keep looking until data is able to be received

     'following routines here
Loop


Is there is a way around it?

Cheers,

Yves
   

[top204]

That is the major flaw, amongst other flaws, in the Microchip implementation of the USB tranceiver. It requires the program to constantly keep it alive, which I always thought was a very silly method. It should have been maintained in the background, until it was disabled.

You will need to create a slow interrupt handler that calls the USBPoll command.

That and other flaws are the reasons I do not use the USB trancever on the PIC microcontrollers. IMO, they are very clumsy to work with and are not always reliable, because if the program goes a tiny bit wrong, the USB falls off and will not always re-enumerate.

I've always found it better to use a seperate USB device, so it is always working, regardless of what the program in the microcontroller is doing. :-)

[tumbleweed]

That is the major flaw, amongst other flaws, in the Microchip implementation of the USB tranceiver.

That's not really a Microchip flaw, it's just the way USB works.

The host continuously polls devices, and if they don't respond in a timely fashion (typically only a few msecs) it kicks them off the bus.

I agree though, it's a royal pain, and having something else handle that makes life easier.

[Yves]

Hello,
I found the way to avoid the polling of the constant requirement of sending an empty string to get the the USB sending data by placing the start of the do...loop under the "  USBIn 3, In_Buffer, Auto " just after the " Until Carry_Flag = 0". Now i can send data continuously to the com port. As Tumbleweed says the routine must be short and sweet as the connection drops with the com port very quickly. Now I have my USBCDC routine running continuously.
Many thanks.

Regards,

Yves
       

[Yasin]

Click Start and then Run.

Note If you are running Windows Vista, click Start and then use the Start Search box.

Type regedit and click OK. The Registry Editor opens.

Locate and click the following registry subkey:

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\USB

If there is a DisableSelectiveSuspend registry entry, double-click it. If the entry does not exist, create the entry. To create the entry, follow these steps:

On the Edit menu, point to New, and then click DWORD.

Type DisableSelectiveSuspend and press ENTER.

On the Edit menu, click Modify.

To disable the Selective Suspend feature, type 1 in the Value data field and click OK.

There is such a solution on Microsoft's support site. Interfering with Regedit. It is necessary to try.

https://support.microsoft.com/tr-tr/topic/usb-ayg%C4%B1t%C4%B1-%C3%A7%C4%B1kar%C4%B1ld%C4%B1ktan-veya-tak%C4%B1ld%C4%B1ktan-sonra-usb-ba%C4%9Flant%C4%B1-noktas%C4%B1-yan%C4%B1t-vermemeye-ba%C5%9Flayabilir-1eaf82a6-04b1-2604-f096-2345d9c215ef

[Yves]

There is such a solution on Microsoft's support site. Interfering with Regedit. It is necessary to try.

Thank you Yasin, This is interesting I will have a try but i suppose it is better doing a registry back first before modification and test all other items that may be connected to the USB.

Regards,

Yves