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]

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

[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

[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,

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.

[waclawek.jan]

Hi @Peter L. ,

I know this is an old thread, but I wonder, were you able to get the DFU bootloader to work with the external oscillator?

Thanks,

JW

[PS-PabloGS]

Hi @waclawek.jan,

My company had a similar issue when working with STM32MP1 series. 

Regarding STM32MP153 advanced Arm<Sup>®</Sup>-based 32-bit MPUs - Reference manual point 10.4.2 HSE Oscillator.

Our hypothesis was that ROM Code failed to configure HSE Bypass because a 1K Ohm impedance was required to be connected to Vdd or GND in PH1-OSC_OUT pin.

This information is also specified in Getting started with STM32MP151, STM32MP153 and STM32MP157 line hardware development - Application note point 6.1.1

There is another key point. It may be mandatory to give the processor the capability to turn on/off HSE clock.

At point 10.1.1 of the same document (related to clock configuration)

I hope this information can save you some quality time.

Regards,

Pablo

[waclawek.jan]

Hi @PS-PabloGS ,

Thanks for these snippets of information. I'm not sure how, yet, but they certainly form part of the puzzle, too.

JW

[EP.2]

Thanks PS-PabloGS. We had the same problem but on the L151. If it helps anyone else, on the STM32L151 if using an external oscillator (HSE in bypass mode) the bootloader doesn't seem to handle this so you need a pulldown resistor (1k?) or pulldown cap (20pF?) on PH1 OSC_OUT. I think the L151 bootloader uses HSE in analog mode, expecting to see a crystal on both pins, so adding the pulldown on OSC_OUT should allow it to use an external oscillator only connected to OSC_IN without bypass enabled and it should detect the correct frequency.