Integrating freeRTOS to an existing project

bou6 wrote on Saturday, July 16, 2016:

i am attempting to integrate freeRTOS to my application that run on AT32UC3A0512. I downloaded a freeRTOS project example for EVK1100 (it Supports the AT32UC3A) and try to include the kernel source files, so my application hierarchy looks like :

src
   |ASF
   |APP_FOLDER
   |freertos 
       |freertos-7.0.0
          |source

I solved some compilation errors due to unrecognized paths and remove exception.s from freertos folder since i have this file already under ASF\avr32\drivers\intc, in this stage the project compiles.

The strange thing is that with the kernel folder included in the project, the twi_master_read cause blocking, notice that i don’t make any call to the kernel functions nor include it’s header in any of my project files, the kernel folder is just present physically.

However if i exclude the kernel folder from the project all works well.

The question is : is there any redefinition (clocks, pins,…) in the kernel sources that lead to this behaviour, i really can’t see the problem, so if someone have any suggestion don’t hesitate to comment.

Thanks in advance

bou6 wrote on Saturday, July 16, 2016:

In port.c i come to the function _init_startup in the comment it’s said that its " Low-level initialization routine called during startup, before the main function.", could this function be the source of the problem ? , is there other functions that i should pay attention at ?

heinbali01 wrote on Saturday, July 16, 2016:

What do you mean with these :

    freertos
    freertos-7.0.0

What is in that first directory?

It would also be interesting to see the source code of that twi_master_read, to know if it is influenced by port.h

bou6 wrote on Sunday, July 17, 2016:

Thanks for the feedback, i edited the question, freertos-7.0.0 is under the folder freertos, ASF stand for Atmel Software Framework it contains drivers for the peripherals, twi_master_read is a blocking read operation, it waits a flag twi_busy to become false in order to unblock, twi_busy becomes false using twi interruption, what i come to conclude today is that including freeRTOS folder has changed the interrupt controller behaviour. Even the timer interrupt are not working due to the inclusion of this folder.

bou6 wrote on Sunday, July 17, 2016:

After passing few hours debugging i find that the interrupt controller behaviour is changed due to calls to the function sprintf, before calling sprintf the timer interrupts works well and only after calling sprintf function the timer ISR becomes unreacheable, so sprintf + freeRTOS folder in my project causes problems i don’t why ?