westmorelandeng wrote on Thursday, October 24, 2013:
Hello Richard and FreeRTOS’ers,
I see that vTaskIncrementTick was changed to xTaskIncrementTick - was just trying to help with a port and ‘upgraded’ from 7.4.0 to 7.5.3 - I searched this forum didn’t see any mention of it.
Regards,
John Westmoreland
westmorelandeng wrote on Thursday, October 24, 2013:
Richard,
I have had an inquiry regarding the port for the '430 for one of the parts with larger memory - the '6659 which also has a non-contiguous SRAM memory space. I had a port for the '5635 and modified it to run in the simulator (I can’t get that part from TI just yet) - upgraded to 7.5.3 and it is running in the IAR v5.60.2 simulator as the '6659. Note I had to fix the linker map file.
The port ran OK when I had 13KB allocated. I just tried to allocate 30KB and I am getting a stack overflow message even though with the current linker file I have allocated 0xBFFF bytes which is 49K.
Hmmm, I will look into this further.
Regards,
John
westmorelandeng wrote on Thursday, October 24, 2013:
Richard,
I turned off stack checking:
#define configCHECK_FOR_STACK_OVERFLOW 0
set this:
#define configTOTAL_HEAP_SIZE ( ( size_t ) ( 30 * 1024 ) )
and the port is running.
I put the linker control file back to ‘normal’. In this port, however, I am allocating almost all memory on the RTOS’s heap. All arrays, including 2 dimensional, are all being allocated on the RTOS heap.
So, it may appear there is an issue with the stack overflow checking method.
I will try to get my hands on a real part in the mean time.
Regards,
John
westmorelandeng wrote on Thursday, October 24, 2013:
Richard,
And, when I do this:
#define configTOTAL_HEAP_SIZE ( ( size_t ) ( 32 * 1024 ) )
The IAR linker throws this:
Error[e16]: Segment DATA20_Z (size: 0xffff830d align: 0x1) is too long for segment definition. At least 0xfffec30d more bytes needed. The problem occurred while processing the segment placement command
“-Z(DATA)DATA20_I,DATA20_Z,DATA20_N,DATA20_HEAP+_DATA20_HEAP_SIZE=2400-63FF,F0000-FBFFF”, where at the moment of placement the available memory ranges were “CODE:2504-6305,CODE:f0000-fbfff”
Reserved ranges relevant to this placement:
2400-6305 DATA20_I
6306-63ff CSTACK
f0000-fbfff DATA20_I
Error while running Linker
The segment size is obviously incorrect.
Regards,
John
rtel wrote on Thursday, October 24, 2013:
I see that vTaskIncrementTick was changed to xTaskIncrementTick - was just trying to help
with a port and ‘upgraded’ from 7.4.0 to 7.5.3 - I searched this forum didn’t see any
mention of it.
The change was made to all ports in V7.5.0. Search for “Compatibility information for FreeRTOS port writers:” in http://www.FreeRTOS.org/History.txt. It is a major performance enhancement for ports that can make use of it. A context switch should only be performed if xTaskIncrementTick() returns pdTRUE.
So, it may appear there is an issue with the stack overflow checking method.
It is known that some architectures that have segmented memory have a problem with stack overflow checking (x86 for example), but I’ve just checked the MSP430X demo and, in the demo at least, it is turned on. Maybe there is an issue when it goes above 0xffff (max 16-bit value)? That would seem to be borne out by your other posts as it appears the linker pukes if you try creating an array over that size.
Regards.
jdurand wrote on Thursday, October 24, 2013:
Have the main documentation files been updated? I just searched my PDF file and no version of TaskIncrementTick appears in it. Of course this means the changes doesn’t bother me as I didn’t know it existed in the first place. I imagine there’s other additions I’m not aware of (change history files aren’t the most interesting to browse and I can’t add them to the PDF where I could later find them when needed). Anyone starting off using the documentation is certainly not going to read the change history.
I have “FreeRTOS Reverence Manual” v 1.2.1 (2011), “Using the FreeRTOS…” from 2010 (and one of the paper books).
rtel wrote on Thursday, October 24, 2013:
xTaskIncrementTick() is an internal function, not an API function, hence you won’t find it documented in the reference manual. In the change history it is under info “for FreeRTOS port writers” rather than “FreeRTOS application writers”.
Regards.
westmorelandeng wrote on Monday, November 04, 2013:
Richard - I am going to start another related thread - there is an issue with devices that use RAM > 0xffff evidently.
Thanks,
John