Hello, I just updated to FreeRTOS 7.0.0. and am using the assert functions provided by the RTOS. When running it, following assert fails:

/* Check the alignment of the initialised stack. */
        configASSERT( ( ( ( unsigned long ) pxNewTCB->pxTopOfStack & ( unsigned long ) portBYTE_ALIGNMENT_MASK ) == 0UL ) );

When changing the byte alignment of PIC32 in portmacro.h as follows, the error disappears:

/* Hardware specifics. */
#define portBYTE_ALIGNMENT  4    //was 8 before 

I read that the port alignment was changed in a previous version of FreeRTOS. Am I doing something wrong here or may the check/assert be wrong? Thanks a lot for your support.
Nils my assert macro is as follows:

#define configASSERT( x )  
  ((void)((x) ? 0 : (onAssert__(__FILE__, __LINE__))))

, where onAssert__ is my handler function.

I will try some remote debugging first, before attempting to replicate that here. I would be grateful if you could provide the following information: 1) Have you modified the kernel code at all? 2) Is this the assert that is on line 507 of tasks.c (assuming the file has not been modified). 3) Which memory allocator are you using?  heap_1.c, heap_2.c, heap_3.c, or something else? On the call to xTaskGenericCreate() that triggers the assert, please provide the following information: a) The hex value of pxNewTCB->pxStack at line 469 of tasks.c. b) The hex value of pxTopOfStack *after* line 470 has executed. c) The hex value of pxNewTCB->pxTopOfStack *after* line 502 has executed. Thanks.

Ok – here is a fix. In the file FreeRTOS/Source/Portable/MPLAB/PIC32MX/port.c, find the function pxPortInitialiseStack().  At the very of of that function add the code:

    /* Ensure byte alignment is maintained when leaving this function. */
    pxTopOfStack--;

This should be the first line in the function, and no other lines should be changed. The port was originally written for 4 byte alignment – and later the check constant changed to 8 byte alignment, hence the source of this problem. I will add this to the list of known issues.  Thanks for reporting it. Regards.

By the way – the code is ok as it is provided you are not using floating point string functions – that is the only time I am aware of that requires 8 byte alignment. Regards.

Amazing. Just wanted to give more information, but the support is faster than I am able to report my issues.
It seems to work fine after adding the code line. Thank you! Regards,
Nils.

Hello, yesterday I migrated from v6.1.0 to v7.0.1 on my PIC32.
Now I have problems using the sprintf() function with 4 byte floating point numbers. I tried to comment the “pxTopOfStack-;” and the sprintf() was working correct again. Does this thread only corresponds to 8 byte floating points?
What do I have to do to make the sprintf() working with 4 byte floats?
Is commenting the “pxTopOfStack-;” a proper way? Thanks in advance Thomas

I have just run a test, and this is what I find.  The results are identical when the test is run in main() as when it is run in a task – so I don’t think the cause is anything related to FreeRTOS (no kernel code has run when the test is done in main, so the stack being used is that set up by the linker). First I added the compiler option  -fno-short-double, otherwise floats and doubles were both 4 bytes.  Then I added the following code: // Start of test code /////// volatile float f = 1.23F;
volatile double d = 4.56;
volatile size_t s;
static char cBuffer; /* Check sizeof( f ) is the expected 4. */
s = sizeof( f ); /* Check sizeof( d ) is the expected 8. */
s = sizeof( d ); sprintf( cBuffer, “%f, %f”, (double)f, d ); // End of test code /////// After executing this code, cBuffer contained the string: “0.000000 1.903750” As you can see, both numbers are printed incorrectly. If I don’t include the -fno-short-double compiler option, then all floating point variables are 4 bytes, and I can get correct output for floats, but incorrect output for doubles. Maybe there is a configuration option in the compiler or library that is not set correctly.  I will ask Microchip for advise. Language tool versions: pic32-as.exe v1.12, pic32-gcc.exe v1.12, pic32-ld.exe v1.12, pic32-ar.exe v1.12 Regards. Regards.

Hello Richard, First of all I want to thank you for your quick response. I tried your test code as well but with another Language tool versions.
Language tool versions: pic32-as.exe v1.11(b), pic32-gcc.exe v1.11(b), pic32-ld.exe v1.11(b), pic32-ar.exe v1.11(b).      MPLAB IDE v8.63 The project I’m using is based on a reduced demo of the PIC32 freeRTOS port with the following compiler option:
-g -DMPLAB_PIC32MX_PORT -fno-short-double -Wall -fomit-frame-pointer I ran the tests twice one time with and the other time without the compiler option “-fno-short-double”. Therefore I recognized that it makes no difference on my system. In both cases float consisted of 4 byte and double of 8 byte. Further on I ran the tests, like you, in the main() function and in a task.
My behaviour is different. The sprintf() worked correctly in the main() function
(cBuffer = “1.230000, 4.560000”) but incorrect in the task (cBuffer = “-0.000000, 0.028750”). I did the same test with commented “//pxTopOfStack-;” (line 112 in port.c) which made the sprintf() working correctly in the main() function and in the task. I guess this different behaviour is due to our different language toolset.
Do you think that it is save to comment the pxTopOfStack-; operation? Regards Thomas

I did the same test with commented “//pxTopOfStack-;” (line 112 in port.c) which made the sprintf() working correctly in the main() function and in the task.

I guess this different behaviour is due to our different language toolset.
Do you think that it is save to comment the pxTopOfStack-; operation? That line was only added in in V7.0.1, prior to that it didn’t exist.  It was added in to try and fix the problem you are describing.  If it works without it, take it out, but be aware that you might need to add it back in again when you update your compiler version. I have asked Microchip the question already.  Once I have it working correctly in main(), then I will be in a better position to say if that line needs to be there or not. I think the mistake I made when looking at this before was assuming doubles were by default 8 bytes (which the manual actually says they are).  My tests show that they are not however, so my test was not valid.  This time I actually did a sizeof() test. The default configuration for the compiler and/or the library has changed.  It might be that the project (which was developed with an even older version of the compiler) needs an extra setting somewhere now. I will post back when I hear from Microchip. Regards.

Hi Richard, ok. in the meantime I checked the release notes of C32 v.1.12.
The following link states the change of the alignment of double variables: http://ww1.microchip.com/downloads/en/DeviceDoc/MPLABC32_v1_12_README.html#WhatsNew I’m looking forward to hearing from you soon. Regards Thomas

Try the following code, I have not tried it myself yet, but this is what Microchip recommended:

    volatile float f = 1.23F;
    volatile long double d = 4.56;
    volatile size_t s;
    static char cBuffer[ 50 ];
    /* Check sizeof( f ) is the expected 4. */
    s = sizeof( f );
    /* Check sizeof( d ) is the expected 8. */
    s = sizeof( d );
    sprintf( cBuffer, "%lf, %lf", (long double) f, d );

This was apparently using V1.12 of the compiler (so 32 bit doubles by default) and without -fno-short-doubles – hence the “long double” definition.  It might be that with V1.11 of the compiler you don’t need the long double definition if double is by default 8 bytes anyway. I would be grateful if you let me know if this works as I’ve just put my PIC32 test equipment away. Regards.

Hello Richard, I will try it tomorrow. Regards Thomas

Good Morning Richard, This snippet has the same behaviour on v1.11 as I stated in post 8.
I think one can use this snippet when using the v1.12 of the c32 tool suite. Unfortunately I am not able to test it with v1.12 but it would be interesting if the sprintf() works correctly with v1.12 and freeRTOS v7.0.1 Regards Thomas

I have just tried the code, and found that it works, both in main() and in a task.  However, the compiler generates the following warnings:

main.c:274: warning: double format, long double arg (arg 3)
main.c:274: warning: double format, long double arg (arg 4)

I have played around with the format specifiers and cannot explain the warnings yet.  The code does work though. Regards.

Hello Richard, I got the same warnings but the sprintf() function works correct. I don’t understand how you got it working now.
You only changed double into long double and now sprintf() works fine in both (main() and task)? Regards Thomas