I've been happily working with the Primer2 + CircleOS3.4 connected to an extension board. I was able to make the STM32 'talk' through USART2 with a processor on the extension board itself. The first version of Circle I got was coming with Raisonance environment.
For some obscure reason, when I replace the Primer2_Circle.elf related to version 3.4 (441k)with the newest (related to 3.7 - 591k) in my project, my application (On STM32 primer 2) is still able to *RECEIVE* from USART2 but *NOT to TRANSMIT* through it. I've been debugging for long, checking GPIO configurations, RCC_APB2PeriphClockCmd, I even display GPIOA->CRL, RCC->APB1ENR, RCC->APB2ENR during runs and everything seems OK. What I'm I missing? What kind of upgrade in 3.7 could be disabling my USART2 transmissions?
I actually use interrupts to receive (RX works) but I don't know how they affect transmission. Here are my USART2 interrupt initializations:
/* Enable USART2 Interrupt (this will have to be moved below)*/ NVIC_InitStructure.NVIC_IRQChannel = USART2_IRQChannel; //NVIC_InitStructure.NVIC_IRQChannelPreemptionPriority = 1; NVIC_InitStructure.NVIC_IRQChannelPreemptionPriority = 0; NVIC_InitStructure.NVIC_IRQChannelCmd = ENABLE; NVIC_Init(&NVIC_InitStructure);
...and to transmit I just call the following function:
Therefore, I assume that the problem is caused by the irq (priorities?). There are several issues around the IRQ we have to clean up (but after the contest).
Forgive me if I'm back but there is one point I really don't understand. In my code I just transmit by assigning a value to the data register and then waiting for the USART_FLAG_TXE bit to be set with a poll loop (e.g. no interrupts), more specifically:
/*wait TXE bit to return up after write in data register (before writing next data*/ while(USART_GetFlagStatus(USART2, USART_FLAG_TXE) == RESET);
Can you briefly explain me why you refer to IRQ issues, so that I possibly progress while the contest takes place?
Sorry... I thought you also enabled the xmit interrupt. What I could suggest; - double-check the pin configuration, - check enable bit for transmitter (see page 659 of the RM)
...I assume the bit you refer to is the one that I see at page 463 of the Reference Manual RM0008 (is this what you mean by RM? My manual ends up at page 504)
I display the TE bit of USART2->CR1 register periodically at runtime and it is allways set, the pin configuration was checked.
Please let me know if you have some more hints, Thanks, Adalberto
I had same problem. I solved it by commenting out "Output Compare Timing Mode configuration: Channel1" from TIM_Configuration function. I don't know what is purpose of that configuration code, but everything seems to work without it. I also had to change interrupt priorities to make communication reliable.
looks like things are working with your suggestions but I still didn't have time to understand why and if turning off output compare on timer2 has implications somewhere else in my demo.
However I couldn't hold my emotions and wait longer to return back to you, Many Thanks, Adalberto
I think it has something to do with the fact that same pin is used as USART2_TX and TIM2_CH3 pin. Output compare configuration just blocked USART2_TX functionality?
Usart2 without Circle run fine, but with circle(3.8) TX pin is always high. If I want use circle I must do, when init usart :
void Usart2Init(void) //(u16 baudrate)
{
TIM_DeInit(TIM2); // what i have added as said kkinnune (I think!) ! USART_InitTypeDef USART_InitStructure; GPIO_InitTypeDef GPIO_InitStructure; NVIC_InitTypeDef NVIC_InitStructure;
//bla bla bla .........................
1) There is a better mode to make Usart running? 2) Francis said: ''Therefore, I assume that the problem is caused by the irq (priorities?). There are several issues around the IRQ we have to clean up (but after the contest).'' There is now a 'cleanup' ?
