How to run USB DFU bootloader from HSE oscillator ? (need bypass )

[Peter L.]

Hi,

I have a project that was design to be easily upgradable by the customer during devellopement. For this we added a USB connector and a jumper to select boot mode at power on, so we can use DFuSe to boot the new image. On the dev board (STM32F3discovery) everything is working even with craptastic wiring. However on the final board, it is not working. The USB is not recognized by windows.

The circuitry on the USB lines matches exactly the dev board but the oscillator has changed. On the discovery it is a 8MHz crystal and on my final board it is an external oscillator at 24MHz. Meaning we use the bypass in our application instead of a normal oscillator configuration. This was unfortunately changed during layout.

Is there any way the USB DFU bootloader can work with this external one pin oscillator ? Any tricks I could use to get it working or just impossible... I know it is needed to set the bypass in the application code but does the bootloader take this into account ... ?

Thanks a lot.

Misc data : STM32F303C, 24MHz ext osc ASV-24.000MHZ-EJ-T connected on OSC_IN

 

Refs :

* AN2606 - Application note - STM32 microcontroller system memory boot mode

* Dfuse : https://www.st.com/content/st_com/en/products/development-tools/software-development-tools/stm32-software-development-tools/stm32-programmers/stsw-stm32080.html#resource

[waclawek.jan]

On Disco, unless it's you who installs the crystal, there's no crystal at the target, only one at the STLink. So, basically, it's the same "oscillator/need bypass" situation. If this works, the bootloader somehow copes.

Try

• using 8MHz oscillator (heck, wire it up from the Disco)
• check if there's nothing on the other bootloader-"active" pins which would switch the bootloader to some specific non-DFU mode
• making sure you're in bootloader mode (e.g. deliberately trying to start some of the other bootloader interfaces, or installing a "blinky" as application through SWD)

JW

[Peter L.]

Hi Jan,

Thanks for looking into this and the tips. Below my comments :

1) You are right regarding the discovery board. I looked too fast and the 8MHz is indeed the one for the JTAG programming and co, not for the uC. Will see if I can find spare external oscillator and mount it on the disco board for testing.

2) Double checked and there is only one pin relating to boot and a bit that reset on cold boot. It is the same I use on both boards.

3) Sorry I forgot to mention that I have indeed on application running already, and I can confirm it does not run the application code once I set up the Boot pin mentioned above. So the boot mode is activated and USB has priority avor USART modes (no uart is communicating at boot anyway).

Regards,

[Lubos KOUDELKA · Accepted solution]

Hello,

are you able to connect using SWD to your board running in bootloader (connect to running target) and read out PLL setting done by system DFU bootloader. This can help you to verify, if you face the problem with HSE frequency detection caused by imprecise HSI frequency (there are multiple allowed HSE frequencies and using HSI is determined connected HSE frequency). But HSI deviation may be too high to detect correctly HSE. Lower HSE frequency tolerates higher HSI deviation. This problem is described in AN2606:

"For STM32 devices embedding bootloader using the DFU/CAN interface in which the 

external clock source (HSE) is required for DFU/CAN operations, the detection of the HSE 

value is done dynamically by the bootloader firmware and is based on the internal oscillator 

clock (HSI, MSI). When (because of temperature variations or other conditions) the internal 

oscillator precision is altered above the tolerance band (1% around the theoretical value), 

the bootloader might calculate a wrong HSE frequency value. In this case, the bootloader 

DFU/CAN interfaces might malfunction or not work at all."

Best regards,

Lubos

[waclawek.jan]

Oh, and application uses USB successfully?

If not, maybe it's simply the case of swapped (it happens surprisingly often) or misconnected/bad solder joint on DP/DM pins? That could be detected by wiggling the respective pins as GPIO output and observing.

You've made sure the oscillator is oscillating and surely connected to the respective pin, I presume.

JW

[Peter L.]

Hi Lubos,

Good suggestion, will do and keep you posted about my discoveries on the PLL and clock config when in boot. I indeed should be able to debug and observe the registers in such state.

Jan,

I have my application running but it does not use USB, so I cannot say if it works with the bypass without a high dev overhead.

I had a wrong frequency originally with the external oscillator but it was because the bypass was disabled. Now it is enabled and I have check the clock thanks to the MCO output and it matches my expectations. So the external oscillator, when configured correctly, does work. My fear is that the bypass is not supported / detected by the bootloader. In such case I had like 1/3rd or 1/9th of the frequency instead.

For pin swapping, I have triple checked the connections from the usb cable to the pin of the uC and compared with the discovery and it matches. I had inverted RX and TX on the uart but USB seems correct so far. Same for the 1.47 kOhm on D+.

Regards,

[Peter L.]

Hi,

based on your advice "are you able to connect using SWD to your board running in bootloader (connect to running target) and read out PLL setting done by system DFU bootloader.", did some tests and here is what I retrieved :

 

* On the discovery, working DFU bootloader over USB, register RCC_CR reads 0x030b5783. Not sure how and why it detects an HSE as crystal is not mounted ...

* On my board, DFU bootloader running allow for UART bootload ! It confirms the bootloader is working but most probably does not detect the clock correctly.

* On my board, DFU bootloader running but no working USB, RCC_CR is 0x03004b83. Meaning that HSE is off as well as the bypass. Probably the bootloader does not detect a crystal and continues on HSI instead.

* On my board, if I change RCC_CR from 0x03004b83 to 0x01054b83 in the debugger (setting HSE on, bypass on), it ends up with 0x03074b83 (meaning the HSE turns to ready). It confirms that when bypass is enabled the HSE is correctly detected and set to ready.

* On my board, resetting the chip does not fix the issue, so it is not a race condition on external clock power on.

So if my analysis is correct the bootloader indeed does not enable USB because it runs on HSI instead of HSE bypass (not supported ?). Can you confirm my analysis ? Any way of forcing it to HSE with bypass or it is 100% boot rom without possible forced configuration ?

Thanks a lot.

[Lubos KOUDELKA]

Hi,

On STM32F3 discovery HSE from STlink is connected also to target STM32F3 using SB12, so HSE can be used and detected by bootloader on discovery as well.

If you take a look into AN2606, you can see only UART interfaces are able to work without HSE, for USB HSE is mandatory.

Please be careful, that when UART is detected before USB in system bootloader, USB will be not initialized.

Regarding HSE, please check also RCC_CFGR register to read out, how PLL was set. From this setting it's visible, which HSE value was detected by system bootloader and if it's correct one.

Suggestion made by Jan to try also USB example in user application is also very good for testing. Using CubeMx you can create simple demo faster than reading out register content of system bootloader.

Please check USB training for guidance

https://www.st.com/content/st_com/en/support/learning/stm32-education/stm32-moocs/STM32-USB-training.html

[Peter L.]

Hi,

Noted, but UART is not there in normal conditions, only tried to test as a workaround but my usb testing were performed without any UART connected.

RCC_CFGR is 0x0068040a. Meaning if i'm correct USBPRE = 1 = usb clock not divided and PLLMUL = 1010 = PLL input clock x 12 ... much too high for 24MHz input ... do you think it means HSE detection tries but failed ? HSE ON is off anyway in the end.

Will try to load CubeMx if I have time ... so far if there is no easy fix I bet on forgetting USB and going for UART bootload. Less customer-friendly but better than no upgrade at all.

Thanks.

[Peter L.]

Hi,

Thanks to both of you for your replies. I now have a temporary counter measure using serial bootload and a long term correction modifying the clock for a small crystal to get USB boot to work. That should do it, and worst case if it does not we can keep using serial.

Thanks for the advices and troubleshooting help.

I'll mark this as solved not to forget it without solution.

Bye.