Sure - you can do that. Look at the implementation of USART_TransferSendNonBlocking for what you need to do to kick off the transmission and look at the implementation of USART_TransferHandleIRQ for what all you need to do in your ISR. You cannot expect to call a blocking API and expect the ISR to fire.
The blocking APIs returns after the operation is complete -
Time spent inside the API
<------------------------------------------------------------------------->
+-------------------------------------------------------------------------+
^ ^
| |
| |
| |
Start Blocking Operation The blocking API returns after
the operation is complete.
<------------------------------------------------------------------------->
Time consumed in the operation
The non-blocking API, on the other hand, just starts the operation and returns. Later, when the operation is complete, the corresponding interrupt fires.
Time spent inside
the API
<----------------->
+--------------------------------------------------------------------------+
^ ^ ^
| | |
| | |
| | |
Start Non-Blocking The API returns Operation complete interrupt
Operation after starting the when the operation is complete.
operation
<------------------------------------------------------------------------->
Time consumed in the operation
As should be clear from the above, the recv interrupt will not fire until you kick off the receive operation.
This person uses a button pressed ISR which will fire whenever you press the button and that is why their solution works. I’d still recommend to use semaphore or task notification instead of suspend/resume.
The point to understand is what will cause the ISR to fire.
Also, you are sharing UART between two tasks without any synchronization which is not right. This post has very good discussion about that - Synchronizing UART TX