FreeRTOS Harmony 1.0 TCPIP PIC32MX starter kit

Kernel
1

blavo1 wrote on Wednesday, September 17, 2014:

I’ve integrated the FreeRTOS kernel into my Harmony TCPIP project using the PIC32MX starter kit. I used the cdc_com_port_dual project that was included with the harmony 1.0 ~/apps/rtos/freertos demo’s.

My system_interrupt file looks very similar to the usb project, including the _general_exception_handler.

In my system_init.c, SYS_Initialize function is hitting the _general_exception_handler while initializing the tcpip stack, sysObj.tcpip = TCPIP_STACK_Init().

I haven’t found the culprit yet, but I’ve narrowed it down to the TCPIP_STACK_BringNetUp 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 configMINIMAL_STACK_SIZE ( 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.

2

rtel wrote on Thursday, September 18, 2014:

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.

3

blavo1 wrote on Thursday, September 18, 2014:

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 {
EXCEP_IRQ = 0, // interrupt
EXCEP_AdEL = 4, // address error exception (load or ifetch)
EXCEP_AdES, // address error exception (store)
EXCEP_IBE, // bus error (ifetch)
EXCEP_DBE, // bus error (load/store)
EXCEP_Sys, // syscall
EXCEP_Bp, // breakpoint
EXCEP_RI, // reserved instruction
EXCEP_CpU, // coprocessor unusable
EXCEP_Overflow, // arithmetic overflow
EXCEP_Trap, // trap (possible divide by zero)
EXCEP_IS1 = 16, // implementation specfic 1
EXCEP_CEU, // CorExtend Unuseable
EXCEP_C2E // coprocessor 2
} _excep_code;

static unsigned int _epc_code;
static unsigned int _excep_addr;

/* this function overrides the normal weak generic handler */

void _general_exception_handler( 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” (_excep_code));
asm volatile(“mfc0 %0,$14” : “=r” (_excep_addr));

        _excep_code = (_excep_code & 0x0000007C) >> 2;
        
    }

}