freertos_usart_write_packet does not block!?

soloeng wrote on Tuesday, November 29, 2016:

Reposting new topic:

Has anyone actually tested the USART read to verify it blocks a task? I am using what appears to be the most current FreeRTOS v7.3.0 with ASF (is anything more current?), and a call to freertos_usart_write_packet definitely does not block my task.

I am properly configured with USE_TX_ACCESS_SEM, USE_RX_ACCESS_MUTEX, WAIT_TX_COMPLETE, and WAIT_RX_COMPLETE, and am using 10ms of ticks to block (i.e. 10/portTICK_RATE_MS). The status returned is success.

Using a simple GPIO that I set high before the write, and drop low immediately afterwards clearly shows the GPIO low well before the USART transfer completes.

I did review the PDF usually referenced. I see nothing to suggest I’m doing anything wrong here. I am doing this on an Arduino Due.

Any ideas/suggestions appreciated.

Thank you.

rtel wrote on Tuesday, November 29, 2016:

At the time the drivers were written they were tested very well, but
current version of FreeRTOS is 9.0.0, and in 9.0.0 you cannot use
mutexes from an interrupt which I think the drivers do. In version
9.0.0 you can use direct to task notifications instead - which are more

soloeng wrote on Wednesday, December 07, 2016:


How exactly are you are using FreeRTOS 9.0.0 with Atmel Studio 7.0 ASF? I can only install FreeRTOS V7.3.0. Is there something I can do to update to the latest version for FreeRTOS within the Atmel Studio 7.0 ASF environment?

Frankly, I find the cachphony of open source to be nothing short of complete bewilderment!


rtel wrote on Wednesday, December 07, 2016:

You should just be able to drop the latest source files over the top of
the V7 files in your project.

soloeng wrote on Wednesday, December 07, 2016:

Yes, for the basic FreeRTOS kernel files, but FreeRTOS ported code (such as the function freertos_usart_write_packet that I am asking about in this thread) was developed to abstract the PDC/interrupts from the user so they could use it to write/read and block until the operation completes. That source code is only version V7.3.0 as far as I know, and as I indicate in this thread, does not appear to work correctly.

I’m not sure if it is the FreeRTOS folks or the Atmel Studio 7 ASF folks that are responsible for this. I for one would love an update, or at least an answer to my question about why this functin isn’t working as advertised. I’m just trying to figure this out so I don’t have to keep digging deeper into code that was provided to make life easier. At some point, it’s just easier to re-write the code, which I’m trying to avoid.

Thanks for your help/suggestions. Anything else you can provide, including pointers to the right direction/people, would be appreciated.

rtel wrote on Wednesday, December 07, 2016:

…and in fact I’m not sure the that particular driver is compatible
with the latest FreeRTOS version in any case. I think that was
discussed a little earlier in this thread.

soloeng wrote on Wednesday, December 07, 2016:

That’s fine as I’m not using V9.0.0 (I actually never brought it up), I’m only using the V7.3.0 that is provided by the Atmel Studio 7. I’m finding that it does not work as advertised. That’s what I’m asking about.