F446RE System Memory Boot Mode UART1 PA9 Problem

[Zt Liu]

Posted on October 24, 2017 at 10:38

Hi, everyone. 

I got a strange, also interesting, problem, while I am using System Memory Boot Mode with STM32F446RE.

=================================================================================

Hardware Description

STM32F446, Nucleo-64 Board (PID:0x0421, BID:0x90, Bootloader Version:0x31)

STM32F410 Nucleo-64 Board for comparison

=================================================================================

Host Test Utilities:

ST Flash Loader Demonstrator,

AccessPort (just a PC com port test software)

Prolific PL2302 USB to Serial Module (self made)

=================================================================================

Configuration:

1 BOOT0 pin: 1 (pull high to 3.3V)

2 BOOT1/PB2 pin: 0(pull down to Gnd)

3 This makes System Memory selected as Boot area.

4 UART1 PA9/PA10 and UART3 PC10/PC11 with pullup 100K Ohm Resistor.

5 UARTx TX/RX connected to RX/TX pins of PL2302 

=================================================================================

TRY1:

   Use STM32F446 

UART1 PA9/PA10 => Flash Loader Demonstrator Failed (''Unrecognised device....Please, restart your device and try again'' )

TRY2:

Use STM32F446 

UART3 PC10/PC11 => OK, Flash Loader Demonstrator works!

TRY3:

   Switch to  STM32F410 UART1 PA9/PA10 => OK, Flash Loader Demonstrator works!

TRY4:

   Back to STM32F446 and PA9/PA10 pins, with still the above setup. Oscilloscope shows the following image:

=================================================================================

Problem:

   Due to unknown reason, STM32F446RE PA9 UART1 TX pin is somehow driven low with system memory boot mode pin setup after a reset. This strange phenomena cannot be seen in UART3 PC10 pin, and STM32F410 UART1 PA9 pin.

I've tried that if Boot0 grounded, as normal flash operation, this PA9 driven-low phenomena also cannot not be observed, as the 100K resistor is easily pulled it VCC. I believe this is somehow related to the code in the system boot memory, perhaps not properly configured.

=================================================================================

Work-Around:

   1. Set PA9 TX pin with pull-up resistor down to few kOhm(1K ~ 4.99K Ohm) does the job, with the cost of power consumption.

   2. If I use Com Port Test Software, like AccessPort,  This PA9 driven-low after reset causes the host to receive a 0x00 byte equivalently, hence Flash Loader Demonstrator fails to recognize the device. If this 0x00 byte is omitted, we can still send 0x7F to make UART1 enter boot mode, as I can read chip information using 0x00FF and 0x01FE. Hence a custom flash loader application is still possible.

=================================================================================

Does any have similar experience? Or I just got a damaged F446??

Thanks for reading this post!

.Zt

#system-bootloader #stm32f446 #uart1 #flash-loader-demo #f446

[Tesla DeLorean]

Posted on October 25, 2017 at 14:54

I'm a tool guy, over the years I've written a lot of assemblers, disassemblers, linkers and loaders (compilers really aren't my thing, more of a data/structures guy). Had to build/craft a lot of tools over the years to get the job done.

If the processor can execute stuff within its address space you can typically read/disassemble it. Keil can disassemble anything you point the debugger at regardless of source availability, ie ROM. Their FromELF tool can disassemble AXF/ELF files. I've built my own ARM/THUMB cross referencing disassembler that can take objects, binaries, hex files, etc. It can work automatically, or I can feed it with symbols.

GNU has its objcopy or objdump type utilities

Commercially there are tools like IDA

[Tesla DeLorean]

Posted on October 25, 2017 at 14:56

>>

Didn't you ever occur that our profession is highly recursive?

I like compilers that can compile themselves...