uart broken inside chip? are stm32f103's unusually fragile?

[andy239955_stm1]

Posted on July 30, 2008 at 14:39

uart broken inside chip? are stm32f103's unusually fragile?

[lanchon]

Posted on May 17, 2011 at 12:27

does your firmware hang when trying to tx over uart3, like waiting for readiness? or does the peripheral feedback the software as if everything were fine?

in the latter case take into account this: when you select the alt func for a pin, the AF output signal comes through the AFIO from possibly more than one peripheral simultaneously.

the various sources are effectively ORed together and presented at the pin. so if another peripheral is driving the AF for the same pin high, you'd expect to see the output clamped high like you're seeing.

find out what signals from other peripherals share your tx pin given the current AFIO state, and be sure to remap or disable those signals or their complete peripherals.

[andy239955_stm1]

Posted on May 17, 2011 at 12:27

Anyone dealt with anything like this:

My uart3 transmit signal is stuck high.

I reconfigure the pin as GPIO and can wiggle it.

I remap to alternate pins and the same behavior exists at that pin.

I swap usage of ports between uart1 and uart3 and the firmware that failed to drive uart3 drives uart1 just fine.

My debugger shows identical register settings so I don't have a malformed address for one of the uart access structures.

===

In a similar vein, the nRST pin seems to not do much. I watch it cycle with an o'scope and no registers are set to their specified reset values. I checked that the pin of the chip actually connects to where I attach the scope probe.

===

If I've blown the chip somehow this will be the third one. One of the other deaths was due to a hair-thin strand of wire across some output pins. After that it wouldn't talk jtag.

[andy239955_stm1]

Posted on May 17, 2011 at 12:27

I don't think my problem is an overlap on pin mapping, when I used AFIO to move the uart to the C10,11,12 pins (which have no other alt functions) behavior was the same.

My code progresses as if the transmitter was working fine, I just get a steady high on the output pin.

I note again that hardware reset does not seem to work on my breadboard, it takes a power cycle to get the registers to go to their specified reset levels so this all may be a problem with just this one board.

I will try stm's example code just to make sure this isn't a stupid error on my part.

[16-32micros]

Posted on May 17, 2011 at 12:27

Dear all,

We have identified in some specific cases, that some potential weakness may exist between alternate functions mapped onto the same pin on STM32 and your case described here is one among them. We will release soon ( next week) and errata notice for STM32F10x devices with all details and workarounds. Hope this clarifies more the situation.

Cheers,

STOne-32

[sjo]

Posted on May 17, 2011 at 12:27

I noticed a strange problem with the i2c remapping.

It was cured by moving the actual remap after the gpio was configured.

/* remap was here */

//GPIO_PinRemapConfig(GPIO_Remap_I2C1, ENABLE);

/* Configure I2C1 pins: SCL and SDA */

GPIO_InitStructure.GPIO_Pin = GPIO_Pin_8|GPIO_Pin_9;

GPIO_InitStructure.GPIO_Speed = GPIO_Speed_50MHz;

GPIO_InitStructure.GPIO_Mode = GPIO_Mode_AF_OD;

GPIO_Init(GPIOB, &GPIO_InitStructure);

/* remap UART2 and I2C1 peripherals */

GPIO_PinRemapConfig(GPIO_Remap_I2C1, ENABLE);

may be worth a try.

Cheers

sjo

[jordi]

Posted on May 17, 2011 at 12:27

I've found that enabling all perhiperal clocks, the uart3 Tx doesn't work although in the errata sheet this is only reported when you use the usart3 in synchronous mode ( I use it in asynchronous mode).

Disabling the I2C2 clock solves the problem ( unless you also need the I2C2).

Has anybody noticed the same behaviour?