stm32f417 not able to boot to flash

[kody]

Hi,

I have creating a .bin file configured to make the chip run as VCP. I flashed the .bin using busblaster successfully. But, when I connect the board to USB and check for devices in Device Manager. It does not show up as com port. It is enumerating as STMicroelectronics STM32 BOOTLOADER [2200].

Even though I toggle the switch between bootloader and flash. It is only recognizing bootloader. I tried setting BOOT 0 to high but still no difference.

Please suggest any solution.


Thanks,
Kody

[Jeroen3]

Boot0 should be low during the 4th sysclk.
However, there are OTP en reset options for booting to dfu. Did you set those?

[kody]

Hi Jeroen,

I want to boot to flash memory where my binary is located. But, it is currently being detected as DFU mode(IN USB list of Device Manager)

It should be enumerating as com port.

I did not set any other options like OTP en reset. Is there any other way to make it run the code in flash?

Thanks

[Jeroen3]

Is your binary valid? Does it work when you swd it in?
Maybe your binary need to be signed (as it requires with nxp's dfu and msc-dfu)

[kody]

The binary is valid. I am trying to boot with external clock.

[Jeroen3]

The chip cannot boot with external clock. It always boots on its internal clocks.
Then user code can choose if it wants to switch to external clock.

There are two ways the chip enters its bootloader:
- Method 1: hardware detects a low on BOOT0 and sets the memory remap registers according to BOOT1, if available.
- Method 2: your code does the preparations and jumps to the bootloader ram.
As described in the three links here: https://my.st.com/public/STe2ecommunities/mcu/Lists/STM32Java/Flat.aspx?RootFolder=%2Fpublic%2FSTe2ecommunities%2Fmcu%2FLists%2FSTM32Java%2Fjumping%20to%20the%20bootloader%20via%20software%20does%20not%20permit%20dfu%20mode&FolderCTID=0x01200200770978C69A1141439FE559EB459D758000F9A0E3A95BA69146A17C2E80209ADC21&currentviews=214

You're obviously not doing 2, you'd know. Verify the status of BOOT0 a few uS after reset is pulled high.

If your user code is invalid, as in empty flash, it should do nothing. Some other brands jump to bootloader. Correct me if I'm wrong.

Try to reset all peripherals before you use them. Or do a full chip reset (maybe in software) when the bootloader was used.

[paulie]

- Method 1: hardware detects a low on BOOT0

If I'm not mistaken the bootloader runs with BOOT0 high not low. Normally there is a pull down there for stand alone operation. It's surprising how much confusion there is over this in the tutorials and forums. May be due to mislabeling of those jumpers on MOST of the Ebay STM32 clone boards. The original LCsoft versions were correct.

It is true that the "run user" box must be checked when bootloading or BOOT0 must be low when resetting to run the program. Also note that the board must be reset before another program can be downloaded.

[Jeroen3]

True, I was mistaken about BOOT0 polarity. The reference manual is pretty clear about this. I usually design buttons are active low, thats why. My first post was correct though 

Usually, dfu instructions require the device to perform a full power cycle when completed. This is to prevent any anomalies or remains of bootloader variables in SRAM or other registers.
Please also note that when you haven't implemented a soft-connect/disconnect feature, the USB host will not re-enumerate the device.

[kody]

Is it necessary to enter bootloader mode? To get the external clock run the chip.

I program the mcu with a vcp hse binary by using the normal clock. After powercycle and providing the external clock it does not show up in usb list.

[paulie]

The bootloader does not use external clock but needs user code to do that, as Jeroen3 explained perfectly in reply #5. It pays to read what people trying to answer your questions have to say.

ps. 99.9% of the time when noobs claim their chip is "bricked" or not working as expected it turns out to be a bug in their program or failure to read datasheets. Modern ICs are very hard to damage and factories careful not to ship defective product. Claims of "fakes" and counterfeits are highly exaggerated too.

[kody]

I did read reply.

What I wanted to say was I do not want to enter the bootloader mode.

I want the external clock to drive the chip.

[paulie]

You need to load a program that switches to external clock and bootloader mode is the best way to load a program.

[kody]

I have already set the flags required to enable hse. Would that not be sufficient?

[paulie]

Switching to HSE is not always simple. How do you know external clock is not enabled? USB is not a good way to tell because many other things can prevent that from working. I suggest a simple blinky program to show a big change in rate compared to internal.

It is considered very rude to start new threads for the same question. It's not obvious if this is an age or language problem. Best to at least show country in your avatar. Unlikely sex offenders will track you down with such general info.

[kody]

so enable the required hse flags/settings for sample blinky program and test?

[paulie]

It is considered very rude to start new threads for the same question. It's not obvious if this is an age or language problem. Best to at least show country in your avatar. Unlikely sex offenders will track you down with such general info.

[AndreasF]

so enable the required hse flags/settings for sample blinky program and test?

Yes!

From the various threads here (and on the ST forum) it's quite clear that there are multiple things going on. First it was the question about the external clock, which you claim to have solved. Then it was the issue of the internal bootloader starting up, even though you don't want it to. This is strange, as you wouldn't be able to switch to an external clock unless your chip runs your code (the internal bootloader runs from the internal oscillator). As Pauli said, the (rhetorical) question is, how did you verify that you indeed ran from the external oscillator, after you fixed it? You know there is a bit in on of the registers that tells you if the HSE is ready, right? Right???

Lastly, there is the issue of the nondescript binary that you're trying to get to run for some VCP (virtual Com port, I assume) function via USB. There are multiple potential failure points here that would all need to be checked (again, as Pauli said). It sounds like that was running at some point in time. So, can you go back to that original hard- and software configuration to make it work again?

So, yes, the best course of action is to check one thing at a time with as simple as possible code, then incorporate that code into more complex code. USB is not simple.

[paulie]

I see now dannyf had the KISS philosophy covered in one of the duplicate threads. OP would be wise to heed the same advise from all directions now.

Andreas, I have a question that's been bugging since I came here. Whats with the periodic table avatar photos? Is this a secret cult or something to do with the forum? Do you get one for buying a tee shirt? Is it explained anywhere?

[Jeroen3]

Use ST's peripheral library for clock configurations. Or steal them from a working project, a random RTOS such as chibios for example.
You cannot "just enable the flags".
You'll need to insert waits for it to stabilize, then switch multiplexers and reconfigure the PLL, which is a entirely new story.

[AndreasF]

...
Andreas, I have a question that's been bugging since I came here. Whats with the periodic table avatar photos? Is this a secret cult or something to do with the forum? Do you get one for buying a tee shirt? Is it explained anywhere?

I have no idea, really. It was just one of the built-in options on this forum, so I picked one that sort of fits for me.

[kody]

Use ST's peripheral library for clock configurations. Or steal them from a working project, a random RTOS such as chibios for example.
You cannot "just enable the flags".
You'll need to insert waits for it to stabilize, then switch multiplexers and reconfigure the PLL, which is a entirely new story.

The waits are already presenting in existing system_stm32f4xx.c

By setting the pll values the mux is being switched and pll is reconfigured.

thet is why the main difference is setting the pll values and enabling the flags

[paulie]

I have no idea, really. It was just one of the built-in options on this forum, so I picked one that sort of fits for me.

Well that's a big disappointment. I was hoping it was some secret society like Freemasons or the Opus Dei prelature. I never "applied" for a photo so didn't notice. Thanks for explaining.

Kody from Canada! So we are not too far away unlike some of these dad burn furriners.

For getting a handle on the PLL/HSE tangle this file from westfw in the $1 thread was key to understanding for myself and a couple friends who wanted to know exactly what goes on behind the scenes. C versions were less help there so hopefully you won't be scared off by the "a" word. He even included a table and discussion of wait state requirements.

[kody]

So we are not too far away unlike some of these dad burn furriners.

For getting a handle on the PLL/HSE tangle this file from westfw in the $1 thread was key to understanding for myself and a couple friends who wanted to know exactly what goes on behind the scenes. C versions were less help there so hopefully you won't be scared off by the "a" word. He even included a table and discussion of wait state requirements.

That is quite racist.

should the hseon flag be turned off? when hse bypass clock is being used?

[paulie]

IDK about racist. Maybe nationalist or xenophobic. Not sure what "race" canadians are but I'm half kanuck myself.

To be honest your question doesn't make too much sense to me. I do know the procedure in that code works and have successfully tried several different versions to change the blink rate and experiment with wait states. Obviously every step is included there with nothing hidden. Westfw does provide a more detailed explanation later in that thread:

https://www.eevblog.com/forum/microcontrollers/one-dollar-one-minute-arm-development/

[westfw]

clock configurations.

Do you understand that the ST chips are fundamentally different in their clock configuration from something like an AVR (or most other 8bit chips?)  On an AVR, the clock source is controlled by fuse bits, and you can program the fuse bits ONCE for a desired clock, and it will stay that way while you load multiple other applications in the code memory.  Arduino does this, for example.

On the ST ARM chips (and quite a few other ARMs), EVERY APPLICATION has to configure the chip's clock in whatever way is desired.  The chip ALWAYS starts running on the internal RC clock, and you have to do the (rather complex) dance with enabling the HSE oscillator and configuring the PLL if you want the application to run at "full speed."

Each method has advantages (you can't brick an ARM by configuring it for an external crystal when there is none connected) and disadvantages (I count at least 64 bytes of code to configure a PLL-based clock.)

I don't know if this has anything to do with not being able to run your app from flash.  :-(
Some USB apps (probably including the bootloader) set up the clock to run from a USB-based PLL rather than either HSI or HSE.  I think.

[kody]

^ That is useful info @westfw