$100 prize to fix USART3 Code

[design5]

Posted on October 08, 2008 at 14:24

$100 prize to fix USART3 Code

[design5]

Posted on May 17, 2011 at 12:47

Fellow STM32 Programmers:

I have had no success in getting my USART3 main() program to transmit data via pin PB10 on the 64-pin package. I have spent over 20+ hours attempting to find why my main() code does not transmit via PB10 (when not re-mapped) but does transmit via PC10 (when re-mapped). My main() file is attached, and it can be put into any Keil or IAR evaluation kit with an STM32F103RBT6 device. You can test my main() by removing the comment from line 136 of main() to allow re-mapping, observing the PC10 activity with an oscilloscope, then replacing the comment to disable remapping, then observing the lack of PB10 activity with an oscilloscope. My main() generates a pulse on PA0 which can be used as a synchronization reference pulse for the oscilloscope to assist in locating the USART transmitted data. I cannot afford to waste any more of my time on this problem, therefore I am offering a prize of $100 to the first individual who fixes my main() code so that it transmits characters via PB10, without remapping, on the 64-pin STM32 package (as in the Keil and IAR kits). To claim my $100 prize, you must run my main() code in your kit, fix my main() code so that it transmits characters via pin PB10, then send the fixed main() file to me (by posting to this forum). When I receive your code, then I will incorporate your fixes into my Keil and IAR kits and verify that it works too. Once I have verified that your code does work, I will post the results to this forum and identify the winner, then I will send the prize money to you via the method of your choice (paypal, mail cheque, money order, or cash, etc). This is not a joke. I am getting tired of being told that USART3 characters come out of PB10 (as they should) by other people, when in fact, I cannot get it to work as it should. It now becomes cheaper to pay somebody else to fix my code rather than waste more time with my code. I look forward to some STM32 genius to solve my problem and prove that the STM32 (64-pin device) does not have a silicon bug. Finally, if nobody can fix my code (including the Moderator) then I, as well as all of you fellow programmers too, will have no choice but to conclude that the STM32 has a silicon bug (in the GPIO mapping of USART3 to PB10 pin). Clearly, if nobody can demonstrate that PB10 transmits USART3 characters, then there must be a problem in the silicon. Thanks for your help, Garry Anderson design@robustfirmware.com mobile: +1-604-805-2555

[16-32micros]

Posted on May 17, 2011 at 12:47

Hi design6, lanchon,

I have tested your configuration on my boards and here is what I found : Test environment: 64-pin package ( Keil, IAR starter kits) - USART3 pins not remapped : TX and RX are OK when only USART3 and GPIOs are clocked - USART3 pins remapped on Port C: TX and RX OK. Now, viewing your main.c , I tested the following : - USART3 pins not remapped ( TX on PB10) and I²C2 not clocked => Transmission OK - USART3 pins not remapped ( TX on PB10) and I²C2 is clocked => Transmission Fails ( TX is always 1 and seems forced by I2C2 cell) I will be back to you tomorrow after checking with my team mates and if it is confirmed a bug, it will added in the Errata-sheet like the case of PB12 when I2C2 and USART3 are clocked. Thank you for your valuable testing. Cheers, STOne-32.

[lanchon]

Posted on May 17, 2011 at 12:47

I imagine this is what happens:

on the I2C bus, the lines have pullups and devices have open collector outputs. I believe devices should never actively drive the lines high (though that would be a good thing for the bus; it'd allow faster speeds on higher impedance pullups). the STM32 I2C macrocell designers had two options for implementing each line of the bus: a) internal output enable for each line is fixed at enabled. internal output data for each line carries the actual transmitted data: low to enable the drain transistor, high to place the output in high impedance. (this option requires that the user program the output type as open drain in the GPIO configuration, otherwise the macrocell would drive the line high.) b) internal output data for each line is fixed at low. internal output enable for each line carries the actual transmitted data: enabled to enable the drain transistor, disabled to place the output in high impedance. (this option doesn't require that the user program the output type as open drain in the GPIO configuration; the line would never be driven high.) I suspect implementers chose option a), and thus this happens: when you enable clock to the I2C macrocell and thus turn it on, the macrocell will float its outputs as a well behaved inactive I2C device should. but the implementation of this behavior depends on the pin being set as open drain: though the macrocell is inactive, it's outputting an enabled output enable signal and a high data signal; this is seen as high impedance at the pin, but only if it's configured as open drain. I2C2 SCL line conflicts with non-remapped USART3 TX line. when both peripherals are clocked, TX internal data will function normally and SCL internal data will be a constant high. the internal data lines are ORed at the output cell and you end up seeing a constant high, which you might have interpreted as the TX ''carrier''. but it's not that TX is not working, it's just being masked. had the implementers of I2C chosen option b), this wouldn't be happening. (none of this is mentioned on the errata doc; this are just educated guesses based on common sense but not on any evidence, so take with salt.)

[lanchon]

Posted on May 17, 2011 at 12:47

hi design6!

[lanchon]

Posted on May 17, 2011 at 12:47

I don't think this qualifies as a silicon erratum. SDA and SCL lines of the I2C macrocell are not optional lines; they have to be dedicated to the macrocell in order for it to be of any use. so when you enable the I2C clock, you're agreeing that the pins will be dedicated. to contrast, the SMBALERT signal of the same macrocell has similar drive behavior, but this one *is* optional. the current errata sheet correctly identifies this as a problem.

however IMHO this affair is definitely a ref manual erratum. ref manual should make it clear that clocking a macrocell actually enables it and all its I/O lines. and that some lines of each type of macrocell are non-optional, and the sole action of enabling clock will claim the lines. and as I said before, for each macrocell type there should be a table at the beginning of the manual chapter identifying which lines are optional (and how to turn them off) and which aren't, so that hardware designers can work on a schematic without knowing the intimate details of how to program each peripheral. finally, the manual should specify how conflicts are resolved (by ORing the data, and doing whatever to output enables), so that they can be diagnosed when they happen. by reading the manual one gets the idea that clock disabling is an optional feature to save power but it's not, it's a required feature to operate the macrocells. even the firmware lib designers, supposedly macrocell experts, were caught in this fallacy: they added the two RCC_APBxPeriph_ALL constants to facilitate enabling of all clocks. this should never be done, but the fwlib invites you. these constants are useless and the source of much grief (like design6's) and IMHO should be removed form the lib ASAP.

[16-32micros]

Posted on May 17, 2011 at 12:47

Could you please precise what is your STM32 sub-family used ( Low-density, Medium density or High density ) ?

[ This message was edited by: STOne-32 on 06-10-2008 22:55 ]

[design5]

Posted on May 17, 2011 at 12:47

To ST Moderator:

The part is Medium Density, as on the Keil and IAR kits, part number STM32F103RBT6. Garry.

[design5]

Posted on May 17, 2011 at 12:47

Hi Fellow Programmers:

Lanchon has won the $100 prize. Apparently enabling ALL clocks creates the problem I was experiencing, as well as other problems not yet disovered. So, ''lanchon'', please provide me with a method of sending the $100 prize to you. You may do it online, or else privately via my email, which is:

mailto:design@robustfirmware.com

. Thank you very much for your help. And for the ST Moderator, thanks for getting the errata fixed ASAP along with the Rev number location fix. Also, as ''lanchon'' commented, perhaps the ''ALL'' option should be removed from the library so as to force the programmer to enable only the peripherals needed, thereby avoiding the problems I have encountered. I, for one, intend to delete it from my library files. Garry.

[design5]

Posted on May 17, 2011 at 12:47

To All STM32 Programmers:

As a temporary measure, I recommend you go to the library file ''stm32f10x_rcc.h'' and comment both lines 186 and 204. Without these defines, you will avoid the problem I have experienced. 186: //#define RCC_APB2Periph_ALL ((u32)0x00005E7D) 204: //#define RCC_APB1Periph_ALL ((u32)0x1AE64807) Happy programming, Garry Anderson.