It can read smartcard data with apdu ,but it always happen usart3 FE error interrupt. The smartcard codes download from stm32 ,and i use latest STM32F10x Standard Peripherals Firmware.
This does not seem related to FreeRTOS. Suggest reaching out to ST.
Thanks.
If it run the applycation without freertos, the usart FE error does not happens. But When add the os , I don’t know why it always happen.I suppose it is about timing question ,but I don’t find where it is,that confuse me very much.
OK, if you think that the error is related to using FreeRTOS, can you give more details about “usart3 FE error”?
“FE” sounds like a hex number 0xFE, is that true? And where do you get that error?
use latest STM32F10x Standard Peripherals Firmware.
The SPL was not bad but it is quite old now. Since a long time ST issues a new library called HAL.
And ,when there exists only one task, that init card and read card, it seems not happens the usart interrupt FE error.
the follwing pic is the IRQ handler
I will try HAL to run my applycation,maybe it can solve my problem.but this is still a issue that confuse me
And ,when there exists only one task, that init card and read card, it seems not happens the usart interrupt FE error.
That is interesting: when you only run a singe task, the problem does not occur.
So with two tasks:
- Does it go wrong immediately? Or only after a while?
- Can you describe what the second task is doing: does it use a lot of CPU time? Does it disable interrupts at some point?
- Does the second task sleep (block, delay) enough to allow CPU time for the first task?
Strange, the RS232 reception is an autonomous process of the USART peripheral. All it needs is a good signal and a proper clock.
Are you using a high baudrate?
Thanks for your apply.
The applycation has two tasks. One is a simple while loop ,which can turn on and turn off the light every 500 ms. The other one is to read the smartcard , this task only read card one time if succuessfully, if failed it will read card again every 500 ms. if succeed. then run delay 1s in loop.
1.The usart3 FE(frame error) occurs ,after I read the card ,not immediately , it can see from the log. And if the error occurrs, it will forever print the FE error.
- The read smartcard task need 2s to read card almost, but the total process does not add taskENTER_CRITICAL except the commond “printf”. Such as:
3 .When usart interrupt FE occurs, the first task can run normally. The usart baudrate is calculated 112500Hz.
Will the task affect read card sequential, and receive the data from smartcard not complete
Framing errors tend to indicate ‘timing’ problems, often wrong baud rates. Could the driver you are using have had some of the hardware setup change by using FreeRTOS? If you are using the STM software, I lot of that ends up having fussy setup requirements.
One thing to note, you said 112500 Hz baud, but that is NOT a standard baud rate, there is a 115200 as a standard baud rate, and the difference is enough to cause problems communicating,
Thank your reply.
I have solve this problem. Sorry for that and It is my mistake. My application repeated use the same gpioB 11 with the othertask smartcard reset port ,and that cause FE(frame error) occors .
I have other question. Why should I add taskENTER_CRITICAL and taskEXIT_CRITICAL when print to usart ? such as below:
Thanks for taking the time to report back.
To answer your second question: If your printf() is implemented to write a string to a terminal, or a UART, and there is more than one task that calls printf(), then you don’t want a switch to another task happening half way through the output. For example, if one task prints “hello”, and after the ‘e’ there is another task that prints “world”, the actual output you see might be “heworldllo”. The critical section prevents that by ensuring a switch to another task cannot occur until all the text has been printed out. That said, a critical section is rarely the best way of doing that because it prevents interrupts from executing for the entire lengthy process of printing out a string. I suggest looking at the FreeRTOS book for more appropriate ways of doing the same.