2013-10-28 07:22 AM
Hi All,
I am working on USART1 device for STM32F429I_DISCO board. [I have already tested my serial device (code) on stm32429i_eval1 board.] I am using following USART setup/pin mapping unsigned int temp; /* Enable GPIOA on AHB1 */ ENABLE_PERIPHERAL_CLOCK(AHB1, GPIOA); /* Select Alternate Function 7 for USART1 pins */ temp = GPIO_READ(A, AFRH); temp &= (0xFFFFF0FF & 0xFFFFFF0F); GPIO_WRITE(A, AFRH, (temp | (0x00000700 | 0x00000070))); /* Select Alternate function for USART1 pins */ temp = GPIO_READ(A, MODER); temp &= (0xFFCFFFFF & 0xFFF3FFFF); GPIO_WRITE(A, MODER, (temp | (0x00200000| 0x00080000))); /* Enable Clock for USART1 */ ENABLE_PERIPHERAL_CLOCK(APB2, USART1); My Questions are Can we test USART1 on STM32F429I_DISCO board? If yes, then above mentioned pin mapping is correct? If yes, then should we use JP4[TX, RX] pins for this purpose?2013-10-28 07:35 AM
You could attach a USB-to-CMOS Serial type adapter and confirm it that way.
You could connect PA9/PA10 with a wire or micro-jumpers, and prove it looped back. You could use a MAX3232 or equivalent type device to generate RS232 levels and add a DB9. For JP4 to work you'd need to do something with SB11/SB15, but that would connect you too the STM32F103 part, which may/may-not provide the serial connectivity you want. I'd suspect NOT.2013-10-30 08:15 AM
Thanks for reply
For this option >>>> You could connect PA9/PA10 with a wire or micro-jumpers, and prove it looped back. Is USART support Loop back mode? It is not mentioned in reference manual For this option >> You could use a MAX3232 or equivalent type device to generate RS232 levels and add a DB9. I have tried to use this option but i receive garbage characters (funny characters) on tera term all the time. My USART driver works fine without any change [RCC, CLOCK; mentioned above] on STM32429I_EVAL1 board but not on DISCO board. Should I do some thing more regarding GPIO/RCC/CLOCK settings? Have any one tested USART1 (PA9/PA10) on this board (STM32F429I_DISCO) Moreover in one of the thread [[DEAD LINK /public/STe2ecommunities/mcu/Lists/STM32Discovery/Flat.aspx?RootFolder=/public/STe2ecommunities/mcu/Lists/STM32Discovery/Help%20me%20USART%20STM32F4&FolderCTID=0x01200200770978C69A1141439FE559EB459D75800084C20D8867EAD444A5987D47BE638E0F¤tviews=210]Help me USART STM32F4], you have mentioned that >>> You haven't explicitly stated that you're using an STM32F4-Discovery board, but if you are PA9 is not usable for a USART pin due to a huge bulk capacitor being attached to it. It means PA9 can not be used for USART testing?2013-10-30 09:00 AM
I'm talking about a piece of wire externally (looping back), this will not be discussed in the manual. You send a character, you should receive a character. Functionality of pin confirmed, baud rate implicitly the same.
You have a different board, right? So comments about anhttp://www.st.com/web/en/catalog/tools/FM116/SC959/SS1532/PF252419
aren't going to impact a completely different design. Check the schematics. Baud rates look wrong, or junk on terminal. You can measure bit times on a scope. Most likely you have wrong HSE_VALUE and/or PLL settings. Thehttp://www.st.com/web/catalog/tools/FM116/SC959/SS1532/PF259094?icmp=stm32f4pr_pron_p3436s_sep2013
has an 25 MHz HSE, thehttp://www.st.com/web/catalog/tools/FM116/SC959/SS1532/PF259090
has an 8 MHz HSE. Settings for one won't work with the other, timings, and expectations will be different. Computation for USART baud rates are predicated on knowing what the clocks actually are.2013-11-08 06:04 AM
Thanks for fruitful response.
Successfully tested the serial driver by