STM32F4 Programming: HAL_UART_RxCpltCallback Function Executed Once on XNUCLEO-F401RE Plate

Hello.
I started my adventure with STM32F4 programming.
I have purchased the XNUCLEO-F401RE plate (compatible with NUCLEO-F401RE)
and I took the course at this link
http://forbot.pl/blog/artykuly/programowanie/kurs-stm32-f4-7-komunikacja-przez-uart-id13472

Well, I did the same step by step as instructed in the course, but for me the program performs the function
HAL_UART_RxCpltCallback only once, then the main program loop still works and sending another
mark to UART has no effect.

Below is the code. The code also includes an SPI configuration because my project
it is also to use this way of communication.

In the main function, I call
HAL_UART_Receive_IT (& huart2, & Received, 1); without which receiving a character from UART does not go to callback at all.

In the main function and in HAL_UART_RxCpltCallback I assigned myself the auxiliary variables Temp and Temp2 which
I watch in STM Studio.

The effect of the code below.
The main loop works all the time.
HAL_GPIO_TogglePin (LED2_GPIO_Port, LED2_Pin); - turns on and off the LED
You can see in STM Studio how the Temp variable is being incremented.

After sending any character by UART:
In STM Studio, I can see the Temp2 value being increased by 1
Another LED lights up - HAL_GPIO_TogglePin (LED1_GPIO_Port, LED1_Pin);
Once again I see how the Temp2 value increases by 1 and is currently 2.
The Received variable receives a valid value from the UART

the end.

Sending more bytes to the UART changes nothing in the interrupt
The LED1 diode is lit continuously, the variable Temp2 is always equal to 2.

I am asking for help to a beginner.
Regards and thank you in advance.

rogeros wrote:

Code: C / C++

Log in, to see the code

Should the HAL_UART_Receive_IT function be sure to pass the pointer address to the UART_HandleTypeDef structure?

Thank you Mr. Piotr for your answer.
As I learn the fastest with examples, do you have a piece of code that supports SPI in an interrupt?

But anyway, I'm bothering me why the HAL_UART_RxCpltCallback function is only performed once.

rogeros wrote:

But anyway, I'm bothering me why the HAL_UART_RxCpltCallback function is only performed once.

I will ask again.
Should the HAL_UART_Receive_IT function be sure to pass the pointer address to the UART_HandleTypeDef structure?

It shouldn't be. My friend @rogeros Read carefully the warnings from the compiler or at least post the compilation log here. This will greatly facilitate the resolution of these types of problems. The type of the second parameter passed to this function also generates a warning (but this is partly the fault of API masterful design from ST ...).

rajszym wrote:

Should the HAL_UART_Receive_IT function be sure to pass the pointer address to the UART_HandleTypeDef structure?

Thank you very much for pointing out the mistake. There is still a lot of learning ahead of me.
After changing the call from

on


The UART started receiving the interrupt data nicely as I wanted.
But I already know where my mistake came from. Well, in the course I mentioned in my
the first post was given two examples.

One shows the reception of one byte and the variable was declared there
uint8_t Received;
and appealed
HAL_UART_Receive_IT (huart2, & Received, 1);

in case of receiving several bytes, an array was declared
uint8_t Received [10];
and already appealed
HAL_UART_Receive_IT (huart2, Received, 1);

My no caution. but for the future, do you know a course that would teach me yet?
when to use pointers, vectors, etc ?? So that I could spot such mistakes myself?

grko wrote:

Buddy @rogeros, carefully read the warnings from the compiler

Thanks also for your help. I'm working on System Workbench for STM32 and after writing some code
I clicked RUN. In Eclipse, no Warnings appeared in the "console" tab, so I thought that
everything is okey. After switching to the Problems tab, I actually noticed the messages about which
you mentioned. Thank you because now I will know to check in there.

This is perhaps one more question.

As I mentioned, I use System Workbench for STM32 and XNUCLEO-F401RE with an external programmer.
When I press RUN I have to manually reset the system for the program to load. (when the programmer starts "flashing"
I press reset). After uploading the program, I also have to press reset to make the newly uploaded program start.
If I don't do this, the message "Unable to reset target" appears in the console
In the STM32 ST-LINK Utility program, in the settings there is an option for the programmer to reset automatically
system before programming (and it works ... the programmer resets NUCLEO before uploading) so I think it
System Workbench for STM32 configuration issue but I can not find programmers to configure, let alone
ST-LINK.

@rogeros Colleague @raszy it was about the first parameter passed to HAL_UART_Receive_IT, i.e. huart2. In my opinion, huart2 should be there instead of & huart2 (as the function parameter covers the global symbol huart2). The second parameter was also passed in the way that generates warning. Also, remove volatile from the Received array declaration. It won't do any good.

Ie The HAL_UART_Receive_IT function call is in two places.
Line 72 and 242.

Ultimately, such a code does not trigger any "warnings".
By actually changing the first parameter in the called function on line 72
made the interrupt work properly. However, if I deleted
& from the call to line 242 the compiler crashed an error.

So I have to read when pointers and vectors are used and when not.

EDIT: I thought synrax was displaying line numbers