STM32L4x6 GPIO PA3 Reset Value

[Marato Gebremichael]

Posted on June 01, 2018 at 15:36

Hi guys,

I'm having some troubles understanding the behavior of the ST GPIO on start-up, specifically PA3 on STM32L496VE micro.

Background:

I'm trying to program/flash a SiLabs BT121 (Bluetooth module) chip and have the following configuration on my board:

I'm using a dev kit offered by SiLabs, DKBT, to program the BT The dev kit acts as a USB to UART converter to interface the UART on the BT

On the MPU host side I have PA0 to PA3 configured as UART as follows:

When programming the BT121 the datasheet advises to keep the host MPU in reset state to keep lines floating.

Here's my issue: whenever I try to program the BT121 w/ a MPU that's erased/not programmed it fails.

If I keep the MPU in reset manually (pulled the NRST pin low) thenprogrammingis successful.

Following capture is for the TX (pink), RX (green), RESET (yellow) and BOOT0 (blue) pins on the initial reset dip that puts the BT121 in the DFU mode which allows me to program it.

NOTE: Reset and BOOT0 are the pins on the BT121 chip and not the STM micro.

What I'm seeing from the captures is that a failed attempt to program the BT121 is caused when the BT-TX line does not go low in line with the RESET pin.

From my understanding on an erased MPU all the lines (except the JTAG pins) are supposed to be configured as analog input floating. I verified that with the reference manual:

I went ahead and programmed the specific pin on the MPU as analog mode then as input Push-pull and both seem to work, I was able to program the BT But then I realized that even if I flash and empty program into the MPU the programming of BT121 works.

Finally, Ifigured out that by just simply connecting to the MPU via the ST-Linkto the JTAG brings the MPU into a state where I'm able to program the BT121 chip.

Am I missing something? By the looks of it PA3 is not configured as floating analog inputwhen completely erased.

Thank you! I appreciate any input.

edit: added note for the scope captures.

#uart #gpio #stm32l496ve Note: this post was migrated and contained many threaded conversations, some content may be missing.

[Tesla DeLorean]

Posted on June 01, 2018 at 16:29

With BOOT0 High it is going to be running what is in ROM, not what's in your FLASH (or not). The BOOT0 pin of the STM32 should be pulled low for normal operation, letting it float will result in unexpected behaviour.

You should review the App Notes related to the System Loader, and its pin utilization and expectations.

[Marato Gebremichael]

Posted on June 01, 2018 at 16:33

My apologies, the BOOT0 pin and the RESET pins in the captures are for the BT121 module and not the STM micro.

[Max]

Posted on June 01, 2018 at 18:02

You may be impacted by the bootloader in system memory as it can be executed automatically when the flash is empty. This is depending on your option bytes settings (see

http://www.st.com/content/ccc/resource/technical/document/reference_manual/02/35/09/0c/4f/f7/40/03/DM000835pdf/files/DM000835pdf/jcr:content/translations/en.DM000835pdf

chapter 2.6.2 for details).

The bootloader will configure the STM32 to be reprogrammed through a set of serial interfaces. This may impact your application.

You can find details about what is configured by the bootloader and on which pin in

http://www.st.com/content/ccc/resource/technical/document/application_note/b9/9b/16/3a/12/1e/40/0c/CD001675pdf/files/CD001675pdf/jcr:content/translations/en.CD001675pdf

, as suggested by

Turvey.Clive.002

.

[Marato Gebremichael]

Posted on June 01, 2018 at 22:15

Interesting. 

Considering the table 2 from ther AN2606 app note:

The Boot0 pin in my application is pulled low and the main flash is empty (erased). I don't think I set SW Boot0 pin in any way since the issue is found on a untouched (fresh) micro.

The embedded bootloader enables the HSE and this is not happening in my case.

[waclawek.jan]

Posted on June 04, 2018 at 19:00

Max, Clive,

but even if the bootloader would kick in, PA3 should be set to USART2_RX and that is effectively input, isn't it?

JW

[Tesla DeLorean]

Posted on June 04, 2018 at 20:09

The loader doesn't use it as USART2_RX initially, it usually connects a TIM and measures pulses/glitches to determine an active interface and bit timing.

[Jan Waclawek]

Posted on June 04, 2018 at 20:24

That still sounds input-ish. Even with pullups on it shouldn't hold another mcu (or 'normal' IC) pin hard up.

Is there some simple and definitive way to prove or disprove the bootloader theory?

JW

[Tesla DeLorean · Accepted solution]

Posted on June 04, 2018 at 21:41

Create a minimal FLASH vector table that a) loads SP/PC and points to a 'B .' loop, b) loads SP/PC with values pointing at System Loader, c) have code in Reset_Handler that sets board hardware and then jumps to ROM

Note where aberrant behaviour recurs

[Marato Gebremichael]

Posted on June 04, 2018 at 22:22

Thanks Jan and Clive for the information so far. 

Why can't I assume that the Bootloader is not loaded, considering the HSE is being enabled (common for all bootloaders) and I'm not seeing any activity on the 8MHz external crystal on the board?

Thanks!