2008-10-08 05:24 AM
$100 prize to fix USART3 Code
2011-05-17 03:47 AM
design6-
Thank you - closing the loop as you have will benefit many. Congrats to lanchon - (perhaps he can get back on the ''approved for samples'' list now)2011-05-17 03:47 AM
thanks design6, I'll email you.
I wanted to mention a few thing about your init sequence. (these comments come from memory, so they might be wrong.) here's a section: /* Flash 2 wait state */ FLASH_SetLatency(FLASH_Latency_2); ... /* Select PLL as system clock source */ RCC_SYSCLKConfig(RCC_SYSCLKSource_PLLCLK); ... /* configure PCLK2 */ RCC_PCLK2Config(RCC_HCLK_Div1); /* configure PCLK1 */ RCC_PCLK1Config(RCC_HCLK_Div2); /* Enable Prefetch Buffer */ FLASH_PrefetchBufferCmd(FLASH_PrefetchBuffer_Enable); ... /* Enable Clock Security System(CSS) */ RCC_ClockSecuritySystemCmd(ENABLE); I think I remember that the flash prefetch must be enabled in order to use 2 cycle latency, so that configuration should be moved to the top (but maybe I'm wrong). I don't know what's the default value for PCLK1, but if it's RCC_HCLK_Div1 then you'd be briefly overclocking the peripherals on that bus. I'd move the PCLKxConfigs up before switching over to the fast PLL clock to be on the safe side. and enable CSS before switching to an external clock too, be it direct or via the PLL; that'll guarantee coverage.2011-05-17 03:47 AM
@d6,
I've just sent you an email from lachon@...); just now I realize that anyone could have impersonated me and collected the price :) @jj, thanks!2011-05-17 03:47 AM
I got the cash, sweet!
thanks design6!2011-05-17 03:47 AM
Hi design6, lanchon
Here is the explanation of the observed behavior. Indeed, Application can not use at the same time I2C2 (main pin are SCL & SDA) and USART3 (main pins are RX, TX) as soon as a peripheral clock is enabled the pin took their default value (one in case of I2C) Therefore, the OR between I2C and UART3 makes what you observe : (always level one on usart TX). Cheers, STOne-32.2011-05-17 03:47 AM
Dear STone-32 Moderator:
What we have is a mix-up in philosophy and design. Next time you discuss revised silicon with ST, please request that they be consistent with their design philosophy. Either enabling a peripheral (way of clock or other means) takes control of the I/O pins (like the Atmel devices) or it does not take control (meaning extra code is required to connect the peripheral to the I/O pins). There should not be a mixed philosophy (some peripherals do, some don't). Either the I/O pin allocation is automatic, or manual. ST should make up their mind which way to go on all peripherals. No exceptions. So, I think another silicon revision is in order. While you are talking to them, perhaps you could suggest a rational revision numbering system, such as C,D,E (etc) for future revisions. Please let me know when the new errata has been released. I will check it for correctness. Thanks, Garry Anderson.