i'm trying to use USART2 with primer2 changing the circle os (not using circle application). Thats because i want primer 2 to run just my program .
The problem is that i configured the serial port just as i configure it with my other STM32F103 hardware (another hardware project) thats work fine. And it works fine with primer 2 too just when i finishing recording microprocessor and code starts to run. It is using a RS485 chip and it starts to ask and receive data at network correctly. But, when i turn it off shutting down with the button (i maintain a lot of os functions, just run out with menus, lists, toolbar, etc...) and turn on again, no TX data appears on pins when i connect the osciloscope.
My serial.c have a SERIAL_Init function called at main together with another init functions. It completelly starts the serial. A new Handler for serial was created, SERIAL_Handler and it is added to the scheduler. It uses the usart pins available at the exp connector.
Again, as i said, it works perfectly when i finish recording. After a power down/up, it not send data to the network. I put a LED to blink when i get inside the SERIAL_Handler and it stills running the task and running the send function too.
no, i didn't found this in any part of the xxx_Init() functions. After all, all init functions is been started after the record too. I saw that the shutdown function just change a pin level to turn off power supply and go to battery. And returning from this condition the problem occurs, even running all init functions again.
problem with hardware handshake it's impossible because if it is, serial should not to work at any condition. Now i have the code with me to post here.
Code:
USART_InitTypeDef USART_InitStructure;
GPIO_InitTypeDef GPIO_InitStructure;
/* Configure USART RS485 Rx as input floating */
GPIO_InitStructure.GPIO_Pin = SERIAL_RX_PIN;
GPIO_InitStructure.GPIO_Mode = GPIO_Mode_IN_FLOATING;
GPIO_Init(SERIAL_PORT, &GPIO_InitStructure);
/* Configure USART RS485 Tx as alternate function push-pull */
GPIO_InitStructure.GPIO_Pin = SERIAL_TX_PIN;
GPIO_InitStructure.GPIO_Speed = GPIO_Speed_50MHz;
GPIO_InitStructure.GPIO_Mode = GPIO_Mode_AF_PP;
GPIO_Init(SERIAL_PORT, &GPIO_InitStructure);
/* UART RS485 Enable pin */
GPIO_InitStructure.GPIO_Pin = SERIAL_EN_PIN;
GPIO_InitStructure.GPIO_Speed = GPIO_Speed_50MHz;
GPIO_InitStructure.GPIO_Mode = GPIO_Mode_Out_PP;
GPIO_Init(SERIAL_PORT, &GPIO_InitStructure);
// liga o clock para este periferico
RCC_APB1PeriphClockCmd( RCC_APB1Periph_USART2, ENABLE );
USART_InitStructure.USART_BaudRate = 38400; //
USART_InitStructure.USART_WordLength = USART_WordLength_8b;
USART_InitStructure.USART_StopBits = USART_StopBits_1;
USART_InitStructure.USART_Parity = USART_Parity_No;
USART_InitStructure.USART_HardwareFlowControl = USART_HardwareFlowControl_None;
USART_InitStructure.USART_Mode = USART_Mode_Rx | USART_Mode_Tx;
USART_Init(USART2, &USART_InitStructure); /* Configure the USARTx */
USART_Cmd(USART2, ENABLE); /* Enable USART1 */
USART_ClearITPendingBit(USART2, USART_IT_RXNE);
USART_ClearITPendingBit(USART2, USART_IT_TC);
/*Enable the USART Receive interrupt: this interrupt is generated when the
USART1 receive data register is not empty */
USART_ITConfig(USART2, USART_IT_TC, ENABLE);
USART_ITConfig(USART2, USART_IT_RXNE, ENABLE);
Modbus_MS_Init(&ModbusMestre);
// tira o pino de enable da 485
GPIO_WriteBit(SERIAL_PORT, SERIAL_EN_PIN , Bit_RESET);
it is the SERIAL_Init function, i use the RX interrupt to mount a buffer and TC interrupt is just to set enable pin on RS485 chip.
With some tests, turning audio, mems, timer1, buzzer tasks off, it works fine. I turn off and on again and serial works fine. There is some other tasks that blocks serial with no special reason.
now the tests shows that just hidding MEMS_init() and TIM_Configuration(), the serial works fine. I saw that mems_init uses SPI port. There is any way that it is conflicting with USART2?
The communication to the MEMS is done from the Timer2 interrupt handler, that is set at the highest priority. I guess that the problem is wihtin the interrupt settings, not with the SPI itself.
I just realized that there was already a similar post about the use of the 'FS_write' function. Disabling the timer2 irq made it working,... Again, we had similar problems with I2C! Conclusion: it seems that the timer2 irq is not properly configured, and sometimes blocks the other irqs. To be investigated...
i already tried to change interrupt priority without success. I have seen similar problems with interrupts with ADC and USB. Using adc end of conversion interrupt stops USB interrupt. The usb configuration is the same as the virtual com example. well, seems to be a stm32 bug? I already contacted ST people to help with this usb/adc problems and i'm waiting for some answer.
Another doubt is about sound hardware. It stops working when i stop timer2 interrupt too. Is there any influence too?
For the FS_Write issue, we had to set the priority level of the irq at the highest level, and it works fine. The timer2 interrupt is used to manage I2C (audio device) and the MEMS as well. If you stop the timer2 interrupt, both the MEMS and the audio device will not be addressed anymore.
now the tests shows that just hidding MEMS_init() and TIM_Configuration(), the serial works fine. I saw that mems_init uses SPI port. There is any way that it is conflicting with USART2?
thanks.
The timer 2 configuration in my copy of CircleOS has
PA2 is on TIM2_CH3, but the timer for the MEMS is the channel 1 of TIM2.
Regardless, there was certainly a change in operation for me when the timer was not intialised.
We made about 15 prototypes, 3 of which had the symptom of no transmitted characters from USART2. After not initialising the MEMs timer (TIM2) the USART started transmitting.
With the timer still in use, if the USART was rerouted to the alternate port pins, it transmitted chars then, but not on PA2 with the timer in use.
Effectively the behavior is strange: - it works with TIM2 disable, - it works with TIM2 enable, but starting under debug session, - it does not work with TIM2 and starting in normal mode.
The behavior is the same when the output of the TIM2 is disable ( TIM_OCInitStructure.TIM_OutputState = TIM_OutputState_Disable;) during the "TIM_Configuration" function of the CircleOS.
I am surprised that some of your prototypes was working and some other not.
So, the solution is to invalidate TIM2 or remap USART2 (not usefull for the Primer), or remap USART1 on PB6/PB7 for access on the Primer's extension (but with the pb of sharing PB7 with FMSC).
To invalidate TIM2 during the init of the application : - TIM_DeInit(TIM2); $1 To revalidate TIM2 at the end of the application : - TIM_Cmd( TIM2, ENABLE ); - TIM_ITConfig( TIM2, TIM_IT_Update, ENABLE );
However, I will ask ST about this strange affair...
In fact, the problem is the configuration of TIM2. It is mandatory to explicitely configure the other channels, disabling the output channels, and not only configuring the CH1. So it will be done in the next CircleOS version. Meanwhile the workaround is always "TIM_DeInit(TIM2);"
.