bringing up a new platform

[jgriessen]

I have a new prototype platform derived from pyboard and G30TH based on a STM32F401CE with 512kb RAM. Any pointers to getting started from scratch appreciated.

I've done a careful layout of HSE and LSE crystals, put board together with squeegeed on solder paste and hotplate reflow that has othe circuits not to do with the MCU working as planned -- my soldering connections seems good.
I have an active FET probe to measure with that has 3pF of added load and see nothing on the crystal drive outputs.

I'm thinking that for a chip from the factory, the first thing it outputs is a response to boot0 volt sequence on USB port.
Is that right?

Here are some photos and diagrams:

https://www.cibolo.com/docs/pyflex_f401_assy_v0.5-1.jpg solder paste
https://www.cibolo.com/docs/pyflex_f401_assy_v0.5-7.jpg soldered prototype
https://www.cibolo.com/docs/culture_sho ... nprt-3.jpg S.S. stencil from pcbway.com
https://github.com/kanzure/culture_shoc ... clocks.png STMCube tool run determined clocks.
https://github.com/kanzure/culture_shoc ... 1.assy.png assy dwg
https://github.com/kanzure/culture_shoc ... 01.sch.png schematic p1
https://github.com/kanzure/culture_shoc ... st.sch.png schematic p2

[dhylands]

The boards that my brother and I put together had issues getting the oscillator capacitance correct.

You should be able to talk to the serial bootloader just using the internal oscillator.

I created some simple C programs that do things like blink an LED. I've been meaning to flesh this out to do more, but haven't gotten around to it yet. You can find my repository here:
https://github.com/dhylands/stm32-test

The NUCLEO-F401RE board definition that I have should be fairly close to what you need.

[jgriessen]

I used an st-link to program a jtag adapter code onto a STM32F103, so now I have 2 tools to observe my new board with. will see tomorrow.

Will an st-link V2.1 do a USB to serial function?

[dhylands]

According to this post: https://community.st.com/thread/30691 yes. You'd need to connect up the appropriate pins.

[jgriessen]

I've just gotten an answer from ST support that is what I needed and I wonder why it was so hard to find. Maybe very few people create new platforms with the more difficult to solder and difficult to verify the soldering is right QFN packages.
Here's the word on first signals out of an STM32 at boot time:

'Will the internal oscillator allow loading code via boot0 and the USB port?'

It will switch over to the HSE once the boot loader detects that there is a host connected to the USB interface. Please see ST's application note AN2606. The bootloader is activated by applying pattern1 (described in Table 2: Bootloader activation patterns). Once detecting that one has the DFU utility connected by USB host (PC) to the MCU's USB port it will use the HSE and it must be a frequency multiple of 1 MHz and ranging from 4 MHz to 26 MHz. Make sure you are not toggling any of the UART pins or other communication lines because once the internal bootloader senses communication on a particular port it locks onto that port.

So that seems to say that DFU mode could be a normal way to load code, but if debugging crystal running, using something that runs without the HSE oscillator is better. So I'm still working on getting my software tools and connectors and wires ready to measure and use jtag and SWD pins.
An2606 may have more on debugging using USART pins.

[dhylands]

I know that the serial bootloading described in my blog post doesn't require an external oscillator.

[jgriessen]

Thanks Dave.

I was looking at doing a serial port method and found an openocd expert so followed that way using jtag pins -- also not requiring an external clock to boot.

So now I have ability to load code, boot and run, but no USB while running. Digging into setting up a REPL on serial port.