Bug in STM32F103: enabling FSMC clock pulls up PB7

[owlm00n]

I have an STM32F103 board call 野火STM32F103ZE_霸道开发板，i found  enable  FSMC clock will pull up PB7  GPIO to 3.26v ,   i try decrease my code ceaselessly to verify this bug, finaly it can reproduce bug easily like this 

#include "stm32f10x.h"

int main (void)
{
//RCC->AHBENR |= 0x100//RCC_AHBPeriphClockCmd ( RCC_AHBPeriph_FSMC, ENABLE );
*( unsigned int * )0X40021014 |= ( (1) << 8);
}

void SystemInit(void)
{
// nothing in here
}

Is this a problem specific to a single chip or a more general chip?

[mƎALLEm]

Hello @owlm00n and welcome to the ST community,

1- This statement is not clear: "野火STM32F103ZE_霸道开发板" even I translate it I got: "Wildfire STM32F103ZE_Dominator Development Board" could you please clarify?

2- First, ensure nothing is connected to the FSMC_CK, do you confirm that?

 

[Andrew Neil]

---

@mƎALLEm wrote:

1- This statement is not clear: "野火STM32F103ZE_霸道开发板" even I translate it I got: "Wildfire STM32F103ZE_Dominator Development Board" could you please clarify?

---

From that translation, I found "Wildfire F103-Domineering-V1/V2 Stm32f103zet6 Development Board Learning Board Core Plate Arm Development Board":

https://www.aliexpress.com/i/1005008868422232.html

@owlm00n - is that the one?

This is why it's important to give a link - so that readers can be certain of what you're referring to!

Are you certain it is a genuine ST chip on the board?

 

[owlm00n]

YES , the the board in picture is same as mine , i give the Github link above, hope it will hlep.

[waclawek.jan]

This is not a bug, it's how the 'F1 GPIO works.

The 'F1 family was the first STM32 family, and its GPIO is a very simplistic design (GPIO in all newer STM32 has a different, more coherent design): the individual modules (like TIM, I2C, SPI, etc.) output signals are simply OR-ed together. Some modules have individual enable bits for their outputs, e.g. in TIM (TIMx_CCER.CCxE), so you can enable the module but not enabling its output it won't influence other module's signal at the same pin; but many modules don't have such individual enables, and all their pins are enabled at once. This is also the case of FSMC, where, once you enable its clock in RCC, its signals start to "occupy" the pins where it is connected.

Pin PB7 is FSMC_NADV, which is used only in (relatively rare) multiplexed-bus designs. ST is aware of the fact that enabling FSMC would occupy PB7 even if you don't need FSMC_NADV signal, so you can disable it by setting AFIO_MAPR2.FSMC_NADV (don't forget to enable AFIO clock in RCC before writing to its registers).

JW

[owlm00n]

Excellent answer, thanks

1-Now I know how it works,  it is diffcult to know without you answer, learn a lot.

 

so you can disable it by setting AFIO_MAPR2.FSMC_NADV (don't forget to enable AFIO clock in RCC before writing to its registers).

---

2-I try this way , but FSMC_NADV bit cat write to True, so PB7 always pullup when  FSMC clock Enable.

[waclawek.jan]

Do you have AFIO clock enabled in RCC?

JW

[owlm00n]

Sure.

Besides，I get it fron Chinese forum，I think it may be a true bug.

 

[waclawek.jan]

Interesting. I didn't know about this erratum.

It should apply only to STM32F103xC/D/E (see STM32F103xC/D/E errata) - as you said you have the 'F103ZE, that unfortunately applies there.

It appears that according to e.g. the larger STM32F103xF/xG errata, the problem has been fixed in those chips. I understand this won't help you with that particular board, sorry.

JW

[owlm00n]

I have checked my chip, it is STM32F103ZET6 same as the schematic, and checked it on the chip (forgot to post),

because I download the STM32F103xF/xG errata first.