Bootloader / USB Oddity. USB Reset needed?

Bootloader / USB Oddity. USB Reset needed?

Postby cmj » Wed Mar 31, 2021 10:01 pm

Hello

A bit of a strange one?

I have a PIC24FJ64GB002 that I am using as a USB host - using with the Microchip USB host code. The PIC then uses SPI to communicate with another system (the PIC is the slave). That side of it is working.

I then added a simple bootloader. It will update the code okay, but when I jump to the main application from the bootloader, if the device (mouse in this case) is connected the USB side doesn't work for maybe a few minutes, then it kicks into life, as if something has timed out and reset something internally.

If I disconnect and reconnect the mouse, it works straight away. If I don't use the bootloader it works from power up. Both the application and loader are in C. I did try a very thing assembler "pre-loader" that would just check the state of a single digital input and either jump to the application or the loader, but even that didn't work (the test here was to set the input to 1, then tell the PIC to reset itself (with asm "reset") via the SPI link.

I suspect there is some sort of timing thing going on, but I can't see what. As far as I can tell the USB system isn't active during the bootloader (the red LED on the mouse doesn't light up until the application starts).

One solution would be to get the application to somehow reset the USB system as if the device had been reconnected, but I couldn't see how to do that.

Any suggestions would be most welcome.

Thanks

Chris
cmj
 
Posts: 4
Joined: Wed Mar 31, 2021 9:35 pm
PIC experience: Experienced Hobbyist

Re: Bootloader / USB Oddity. USB Reset needed?

Postby cmj » Thu Apr 01, 2021 9:12 am

Answering my own post, as there's nothing like posting a question to a forum to make you think of a solution..

Setting the POR bit in RCON seems to do it. I believe (from reading somewhere online) it causes the C runtime to reinitalise itself.
cmj
 
Posts: 4
Joined: Wed Mar 31, 2021 9:35 pm
PIC experience: Experienced Hobbyist

Re: Bootloader / USB Oddity. USB Reset needed?

Postby AussieSusan » Tue Apr 06, 2021 8:27 am

That all depends on how you are passing control between the bootloader and the application.
Normally the C runtime is the first thing to get control on any reset (i.e. the use of the address that is stored at 0x0000 in the program space). The C runtime sets up the stack, initialises global variables etc, before passing control to your 'main()' function. Depending on the C compiler, if the 'main()' function ever exits, the runtime will repeat the startup sequence and re-call the 'main()' function.
If the bootloader is the code that receives control following a reset, and you say that the bootloader is written in C, then the environment that is initialised will probably not be that of your application.
Alternatively if your app received the reset and as part of its startup, it tests to see if the bootloader should be activated, then the story may be quite different.
Susan
AussieSusan
Verified identity
 
Posts: 173
Joined: Mon Jun 16, 2014 4:45 am
PIC experience: Experienced Hobbyist

Re: Bootloader / USB Oddity. USB Reset needed?

Postby HKPhysicist » Sat Apr 24, 2021 7:45 pm

I am new to MCU.
But why do we need bootloader for a MCU?

I just know that a PC can have a bootloader because we can boot the PC to different OSs installed on the hard disk.
User avatar
HKPhysicist
 
Posts: 16
Joined: Wed Feb 24, 2021 5:53 am

Re: Bootloader / USB Oddity. USB Reset needed?

Postby AussieSusan » Mon Apr 26, 2021 7:25 am

In general you don't need a bootloader - and in many cases they can simply get in the way.
Typically in the Microchip world, you develop the app without a bootloader so that you still have access to the various debugging capabilities of the IDE and your programmer.
Once all of the code has been debugged (there will ALWAYS be at least 1 more bug - this is software after-all) you can then look to add in the bootloader part so that you can then distribute the app into all of the 'in field' devices (you don't want to do debugging there so the fact that the bootloader does not provide that capability doesn't matter).
Of course you should always design your app to take into account if it will eventually use a bootloader - the bootloader takes up space so your app can't use all of the available memory; you need to add in the code that lets you boot/transfer control to the bootloader and back again (however you design the interaction between the two) and so on.
The majority of my embedded application development is for my own benefit and so I don't think I have ever used a bootloader except for an Arduino device where there is not much choice.
Susan
AussieSusan
Verified identity
 
Posts: 173
Joined: Mon Jun 16, 2014 4:45 am
PIC experience: Experienced Hobbyist

Re: Bootloader / USB Oddity. USB Reset needed?

Postby Roche » Mon Apr 26, 2021 6:10 pm

I guess my take on it is that it allows a firmware upgrade in the field, without the need for a device programmer. Customers do not always have one, or the PIC may be buried so that it is physically difficult to get to, but there might be access via a serial port.
Roche
 
Posts: 72
Joined: Fri Jul 11, 2014 12:35 pm
PIC experience: Professional 5+ years with MCHP products

Re: Bootloader / USB Oddity. USB Reset needed?

Postby HKPhysicist » Wed Apr 28, 2021 9:08 am

Roche,
You are right.
I find this official information very useful:
https://www.microchip.com/promo/unified-bootloaders

Also, there is an add-on module inside MCC Core v5.02 of MPLAB X IDE.
User avatar
HKPhysicist
 
Posts: 16
Joined: Wed Feb 24, 2021 5:53 am


Return to PIC24

Who is online

Users browsing this forum: No registered users and 7 guests

cron