Hello Simon
Apologies for the delayed reply, we have a new baby boy in the family, born 1 week ago... and things have been rather hectic since then...
Eventually I think I have concluded that the problems I had were not any fault in the ST libraries. My application project worked, but not my sample demo project which was to become my bootloader. I believe that in the end, this is my fault, for forgetting about a specific detail of my hardware.
Specifically: my PCB (this is not an ST Dev board, it is my own PCB design) originally had a 25MHz crystal as the system clock, in a push-pull oscillator composed of an NPN and PNP transistor. It was done this way since the oscillator also acts as reference for an Si5351A PLL Synth chip. I did NOT choose to configure a MCO output of the STM32 since these have various low level spurii which would have been a problem in my application. Then I manufactured a batch of boards. AND THEN, I found I needed greater frequency stability. I replaced the crystal with a 25MHz TCXO which then has excellent stability; to do this I had to make a tiny daughterboard containing three connections (3.3V power, Gnd, and 25MHz output). The way it worked out, the only way to conveniently install this daughterboard was to make use of a spare I/O pin pad of the processor which happened to have been provided in my PCB layout, at a 0.1-inch header strip and was not in use. This spare I/O pin supplies 3.3V at 1.25mA for the TCXO. The I/O pin must be configured as GPIO output and set High by the GPIO_Init() before the system clock init is done. So that the TCXO is powered up. It's an inconvenient arrangement, obviously it would be much nicer to power the TCXO from the 3.3V supply rail but physically that did not work on my already-manufactured batch of 500 PCB Assemblies... that was why I opted to use the I/O pin which was conveniently placed.
I believe my error was that in setting up the Mass Storage Device class according to the ST tutorial YouTube video, I followed the steps precisely; I even configured some other I/O pins which I knew I needed, to disable some parts of my hardware for the demo; BUT, I failed to remember that I needed to configure that I/O pin high, which powers my TCXO. Big doh.
What I *ought* to have done of course, is try again the ST demo video, and this time remember to add the config to power up that I/O pin... but by the time I had it working and realized my error, after several frustrating weeks, I was so excited to continue and make progress that I just continued on with my next steps in my bootloader development!
In the end then I have big fat piles of rotten eggs on my face... thanks to all who responded in this thread kindly, and actually on the plus side, all the debugging I did, I did learn a lot from. All the debugging showed a failure in the USB Core Reset function, a timeout of the command to the STM32 core to reset the USB peripheral; someone further up this thread suggested that would be likely due to incorrect clock configuration. In the end they are CORRECT, the ST library is not any longer under suspicion, it was, I believe, my own fault!
So I progressed further and finished my USB Bootloader with a bit more blood, sweat and tears but no major blockages. What I have now is a bootloader which fits in the lowest 16K Flash sector of the STM32F401RBT6. When the bootloader is run in firmware update mode, my PCB appears to the host computer as a USB Flash drive, containing two files: the firmware binary, and an EEPROM file - which is read from the onboard I2C EEPROM chip. These two files can be read and written from/to the PCB exactly as one would read/write to a USB Flash drive; by copying files in File Manager. It works on Linux, Windows (I tested both) and presumably Mac, without any drivers, without any special software, etc. Because USB Flash drive MSC is already supported inherently by all Operating Systems. In the event that the user copies a new firmware file onto the board, the bootloader erases the upper Flash blocks (112K) and writes in the new binary, then boots into the newly updated application firmware. 256-bit AES encryption is also included which secures the firmware and board such that use of the firmware files on cloned PCBs is not possible, and installation of other firmware on my PCB is also not possible.
All in all I am very pleased with the result.
BUT, Simon, I am not sure that this helps at all with your problem. As I mentioned, in my own case after adding a 38400 baud USART and adding debug statements all over the place, I finally found the failure occurred in the USB_CoreReset() function. This should have been an indicator that the clock configuration was incorrect. You may have this problem, you may have others... I think there are a million ways to fail, and only one way to succeed... but this is not a life philosophy topic...
Everything the kind members of this forum said was good advice and I would suggest you to also follow it; try adding debug statements to see what is going on inside the code. If it so happens that the USB_CoreReset() function is where it fails, just the same as in my case, then it would be worth examining the clock configuration to make sure you really do have 48MHz on the USB clock.
Regards
Hans
