STM32F412 UART Boot no response ...

[Eryk Sokolowski]

Posted on April 06, 2018 at 17:10

Hi There,

I am going a bit crazy about this. I have a custom board with STM32412 on it. 

I have connected TX and RX to PA9 and PA10, I ensure that Boot0 == 1 and PB2 (boot1) == 0 (just in case). As per  AN2606.

And the board doesn't respond to 0x7F.

The same setup with the NUCLEO evaluation board works fine! I use a UM232R @ 3v3 both TX and RX are pulled up internally

What am I missing?

The MCU on the board was tested in its virgin state ( from the box ) and also after programming using JTAG to check if it works?

Any clues or pointer would be much appreciated?

[Tesla DeLorean]

Posted on April 06, 2018 at 17:45

Test the serial port with code you JTAG onto the device

Make sure other pins used by the System Loader are inactive, otherwise it will assume those are the interface to use.

Try 9600 8E1 (EVEN PARITY)

[Eryk Sokolowski]

Posted on April 06, 2018 at 18:38

Hi, thanks a lot

I assumed other pin conflict and I have an unpopulated board with Just the uC , boot and uart pins hooked up.

I will try lower baud i used your settings with 112500 for all my tests.

I tried to avoid the first test JTAG as the software team is quite busy with other tasks, but do you suspect damaged uC?

[Tesla DeLorean]

Posted on April 06, 2018 at 23:42

It should be a 20 minute coding task to get the USART doing something if the chip/JTAG is functional.

Damage to the IC isn't high on my list. If JTAG doesn't work I'd be looking at supplies, reset circuits, AVDD and VCAP issue, and that the orientation of the part is correct.

[Eryk Sokolowski]

Posted on April 07, 2018 at 10:00

Thanks Clive One,

Sorry I didn’t make it clear - the bare board was tested with JTAG and I can identify the STM32F412 and program it via JTAG.

I didn’t think testing rhe UART would be required via software as I connected the pins the same way as on the NUCLEO board and I have scope probes in the line and I can clearly see a request and the MCU doesn’t respond to it on it output TX pin...

Therfore my assumption is that there must be something else preventing it from working... most likely some other pin that needs to be pulled in a certain direction?

was wondering if any of the floating i/o pins could cause it but again they are floating on Nucleo board too?

So in short

1. MCU works and can be programmed 

2. I am sure about the UART that it should work without trying in eSW

3. I suspect either wrong pin config somewhere else or 

memory protection out of the factory?

[Tesla DeLorean]

Posted on April 07, 2018 at 16:43

Board bring-up is a combination of HW and SW expertise, you'll need to turn your assumptions into knowns as part of a design validation process.

[Eryk Sokolowski]

Posted on April 09, 2018 at 16:14

I found the problem -> the RTC was set to Friday past 16:00 so it didn't work.

Change the board to a new one it seems to work exactly like the dev board

Dead mcu on th eold board