usart + sd card interaction

[mailmail9116]

Posted on March 05, 2013 at 14:36

Hi,

I am using STM3240G-Eval , i know that in this evaluation board MicroSD Card shares I/Os with motor control, RS-232 and audio . So i am trying to work around this limitation. I have the following flow : initUSART(); While(1) {      EnableUSARTinterrupts()      waitforinputfromRS232();      DisableUSARTinterrupts();      InitSD();      DoSomeSDStuff();      DeInitSD();   } In the first iteration everything works correctly ,but in the second one i recive wrong data,or i am not receving any data at all ( even though that i re-enabled the interrupts) Any ideas ? Thanks Michael

[Tesla DeLorean]

Posted on March 05, 2013 at 14:52

Disabling the USART interrupt isn't going to preclude interference on it's Rx pin.

What pins are in conflict? I could look but, this isn't my issue. How do you stop/throttle the sending device while using the SD Card? Does disabling the interrupt cause you to overflow the USART, does it signal such an error in the status register?

[mailmail9116]

Posted on March 05, 2013 at 15:10

Hi Clive,

How do you stop/throttle the sending device while using the SD Card? The sending device is a GUI that transmits data from bluetooth to rs-232 ,so i control it,and i know when to send the data.,no problem here Does disabling the interrupt cause you to overflow the USART, does it signal such an error in the status register? I will check,but as far as i see disabling the interrupts,do no good,i still recive interrupts on the USART when using the SD-card. originaly waitforinputfromRS232() is just a loop that waits for ''end of transmit'' flag to raise,the flag is recived from the interrupt function that recives all the data. Another thing that i tried right now is disable the USART interuupts ,and not use them at all ,and in the waitforinputfromRS232() function i just do polling  on the USART_GetFlagStatus(EVAL_COM1,USART_FLAG_RXNE) and do USART_ReceiveData(EVAL_COM1) if the flag is up. and again,the first iteration worked ok , but in the second one,its all gone. Do you think it will be easier for me just to leave the USART and go and use the USB or the ethernet ? Thanks Michael

[mailmail9116]

Posted on March 06, 2013 at 10:51 Hi, Any ideas?

[Andrew Neil]

Posted on March 06, 2013 at 12:04 If it ''works'' (sic?)  first time through the loop, but not subsequent times, does that not suggest that the system state is not being correctly restrored when the loop returns to its start...?

[Tesla DeLorean]

Posted on March 06, 2013 at 15:51

USB and Ethernet are more complicated interfaces.

Ok, so lets revisting the pin issue, what pins are conflicting here? How do you handle that? Showing me a subroutine call doesn't really help me. Do you handle the AF pin source selections correctly so the right peripheral gets the data it wants? If the second go round the loop doesn't work, you need to look real carefully at the code you run between the time it works, and the time it doesn't. Dump out the peripheral registers if you have to, and compare-and-contrast the state where it works vs that which it doesn't. I have ZERO visibility into your situation.