PIC32 FreeRTOS Release Version 1.2.2 - Bug in wilc1000 driver

andylong0206 wrote on March 07, 2018:

Hi Guys,

Has anybody experienced a Data Bus Error Exception when using the AWS FreeRTOS Release Version 1.2.2 configured to WiFi on a PIC32 target?
When configured to use the wired Ethernet all is OK but when on Wifi randomly an exception is thrown.
I’ve been trying to trace it in the wilc1000 driver, but to no success at the moment so I thought I’d throw it out on here.

Thanks

Andy

SarenaAtAws wrote on March 09, 2018:

Hi Andy,

I have left the Shadow demo running for over an hour with the code pulled from https://github.com/aws/amazon-freertos and could not reproduce your issue. Could you provide us with your workflow and if you have made any other code changes?

Thanks,
Sarena

andylong0206 wrote on March 12, 2018:

Hi Sarena,

After much pulling hair out I’ve found the issue. In the demo project, the compiler optimization level is set to 1. My project is 0. If you change the demo project to 0, it will crash within a few minutes.

Now for the reason and the solution. During compilation you will see the following warnings:

…/…/…/…/lib/FreeRTOS-Plus-TCP/source/portable/NetworkInterface/pic32mzef/NetworkInterface_wifi.c: In function ‘xNetworkFrameReceived’:
…/…/…/…/lib/FreeRTOS-Plus-TCP/source/portable/NetworkInterface/pic32mzef/NetworkInterface_wifi.c:174:15: warning: ‘pxNetworkBuffer’ may be used uninitialized in this function [-Wmaybe-uninitialized]
if( pxNetworkBuffer != 0 )
^
and

…/…/…/common/logging/aws_logging_task_dynamic_buffers.c: In function ‘vLoggingPrintf’:
…/…/…/common/logging/aws_logging_task_dynamic_buffers.c:188:29: warning: ‘xLength’ may be used uninitialized in this function [-Wmaybe-uninitialized]

The first being the critical warning and the cause.

Changing the code in NetworkInterface_wifi.c from:


    void xNetworkFrameReceived( uint32_t len,
                                uint8_t const * const frame )
    {
        bool pktSuccess, pktLost;
        NetworkBufferDescriptor_t * pxNetworkBuffer;
        IPStackEvent_t xRxEvent = { eNetworkRxEvent, NULL };

        pktSuccess = pktLost = false;
        ...

To:


    void xNetworkFrameReceived( uint32_t len,
                                uint8_t const * const frame )
    {
        bool pktSuccess, pktLost;
        NetworkBufferDescriptor_t * pxNetworkBuffer = NULL;
        IPStackEvent_t xRxEvent = { eNetworkRxEvent, NULL };

        pktSuccess = pktLost = false;
        ...

Now NO warning and NO crash!!!

I believe not initializing variables, especially pointers is not good practice and can cause some weird issues at compiler optimization level as in this case. Different compilers handle this differently so for consistency initialization is the best way.

I hope this helps everyone.

Andy

SarenaAtAws wrote on March 13, 2018:

Hi Andy,

Thank you for bringing these issues to the light and for your resolution, we will fix them. These warnings show up in the build log for optimization level –O1, but are valid bugs that could cause issues in both optimization levels.

I would also like to mention that we recommend that optimization level –O1 or higher be used as noted by the Microchip MPLAB Harmony peripheral library under lib\third_party\mcu_vendor\microchip\harmony\v2.04\framework\peripheral\peripheral.h:


// *****************************************************************************
/* Refer to the "Prebuilt Libraries" help documentation on Peripheral 
   Libraries for additional information.
*/
#ifndef PLIB_DISABLE_OPTIMIZATION_WARNING
    #ifndef __OPTIMIZE__
        #warning "MPLAB Harmony peripheral libraries are intended to be built with optimizations (-O1 or higher) enabled"
    #endif
#endif

Thanks!
Sarena

Edited by: SarenaAtAws on Mar 13, 2018 3:31 PM