FreeRTOS Harmony 1.0 TCPIP PIC32MX starter kit

I’ve integrated the FreeRTOS kernel into my Harmony TCPIP project using the PIC32MX starter kit. I used the cdccomport_dual project that was included with the harmony 1.0 ~/apps/rtos/freertos demo’s. My systeminterrupt file looks very similar to the usb project, including the _generalexception_handler. In my systeminit.c, SYSInitialize function is hitting the generalexceptionhandler while initializing the tcpip stack, sysObj.tcpip = TCPIPSTACK_Init(). I haven’t found the culprit yet, but I’ve narrowed it down to the TCPIPSTACKBringNetUp function in tpcip_manager.c somewhere in the module init section line 410. Has anyone been successful in getting the TCPIP stack in harmony running with FreeRTOS? I’ve been searching the internet to find clues, I’ve seen some postings regarding ” #define configMINIMALSTACKSIZE ( 2048 )” and using the heap_3.c file. I’ve also seen some postings describing a Microchip app note using the older versions of MLA and freeRTOS. Any help is greatly appreciated with this.

FreeRTOS Harmony 1.0 TCPIP PIC32MX starter kit

Does the TCP/IP stack initialise in a project without FreeRTOS? For example, if you were to try initialising the stack before creating any tasks or starting the scheduler does the initialisation pass? Do you have configASSERT() defined? Do you have a malloc() failed hook defined? Regards.

FreeRTOS Harmony 1.0 TCPIP PIC32MX starter kit

Yes the tcp/ip stack does initialize correctly prior to my trying to integrate freeRTOS. In my current code I am initializing the stack prior to creating any tasks and starting the scheduler. the harmony application that I’m referencing doe have the “void vApplicationMallocFailedHook( void )” defined with a forever and I didn’t take mine any further either. The reference application didn’t define the configASSERT function so coincidently mine doesn’t have it defined either. I did find the Microchip application note AN1264 this morning and I’m starting to reference that to see if it has any relevance to Harmony 1.0. Several search results returned this code slice for debugging exception handler faults so I’m sure it’s very common to use this and I’ll start working with it today. static enum { EXCEPIRQ = 0, // interrupt EXCEPAdEL = 4, // address error exception (load or ifetch) EXCEPAdES, // address error exception (store) EXCEPIBE, // bus error (ifetch) EXCEPDBE, // bus error (load/store) EXCEPSys, // syscall EXCEPBp, // breakpoint EXCEPRI, // reserved instruction EXCEPCpU, // coprocessor unusable EXCEPOverflow, // arithmetic overflow EXCEPTrap, // trap (possible divide by zero) EXCEPIS1 = 16, // implementation specfic 1 EXCEPCEU, // CorExtend Unuseable EXCEPC2E // coprocessor 2 } excepcode; static unsigned int epccode; static unsigned int excepaddr; /* this function overrides the normal weak generic handler */ void generalexceptionhandler( unsigned long ulCause, unsigned long ulStatus ) { /* This overrides the definition provided by the kernel. Other exceptions should be handled here. */ for( ;; ) { asm volatile(“mfc0 %0,$13” : “=r” (excepcode)); asm volatile(“mfc0 %0,$14” : “=r” (excep_addr));
        _excep_code = (_excep_code & 0x0000007C) >> 2;

    }
}