Hello,

MPLAB 8.91
C30 3.31 or XC16
Testing with MPLAB Simulator

I want to port a project from dsPIC33F to dsPIC33EP256MU810.
I took care about the missing declaration of the PSVPAG and modified Linkerscript as follows:
PSVPAG = 0x32;
_PSVPAG = 0x32;
I declared MPLAB_DSPIC_PORT with in the Project macros and exchanged the include directive in FreeRTOSConfig.h to #include .
As the silicon specifies aux-Flash it defines "__HAS_EDS__" I modified port.c as follows:

...
#define portRESTORE_CONTEXT() \
asm volatile("MOV_pxCurrentTCB, W0\n"/* Restore the stack pointer for the task. */\
"MOV[W0], W15\n"\
"POPW0\n"/* Restore the critical nesting counter for the task. */\
"MOVW0, _uxCriticalNesting\n"\
"POPDSWPAG\n"\
"POPDSRPAG
...
and _vPortYield:
...

PUSHCORCON
PUSHDSRPAG
push DSWPAG
MOV_uxCriticalNesting, W0
...
MOVW0, _uxCriticalNesting
POP DSWPAG
POPDSRPAG
POPCORCON
....

So the project compiles and starts running. If reaching vTaskDelay(10); it crashes in portYIELD_WITHIN_API();
What I found is that *pxCurrentTCB holds obviously an invalid adress and so the poped return address will lead to a wrong PC after call _vTaskSwitchContext.

Same Project compiled for dsPIC33FJ128MC804 does work fine.
As my knowledge ends at this point I want to ask you to check this behavior.

Best regards and thanks for your help in advance

Heiko

Code :

//----
#ifndef FREERTOS_CONFIG_H
#define FREERTOS_CONFIG_H

#include

#define configUSE_PREEMPTION0
#define configUSE_IDLE_HOOK1
#define configUSE_TICK_HOOK0
#define configTICK_RATE_HZ( ( portTickType ) 1000 )
#define configCPU_CLOCK_HZ( ( unsigned long ) 40000000 ) /* Fosc / 2 */
#define configMAX_PRIORITIES( ( unsigned portBASE_TYPE ) 4 )
#define configMINIMAL_STACK_SIZE( 200 )
#define configTOTAL_HEAP_SIZE( ( size_t ) 2000 )
#define configMAX_TASK_NAME_LEN( 4 )
#define configUSE_TRACE_FACILITY0
#define configUSE_16_BIT_TICKS1
#define configIDLE_SHOULD_YIELD1

/* Co-routine definitions. */
#define configUSE_CO_ROUTINES 0
#define configMAX_CO_ROUTINE_PRIORITIES ( 2 )

/* Set the following definitions to 1 to include the API function, or zero
to exclude the API function. */

#define INCLUDE_vTaskPrioritySet0
#define INCLUDE_uxTaskPriorityGet0
#define INCLUDE_vTaskDelete0
#define INCLUDE_vTaskCleanUpResources0
#define INCLUDE_vTaskSuspend1
#define INCLUDE_vTaskDelayUntil1
#define INCLUDE_vTaskDelay1


#define configKERNEL_INTERRUPT_PRIORITY0x01

#endif /* FREERTOS_CONFIG_H */

//----
int main( void )
{

prvSetupHardware();

xTaskCreate( MainTask, (signed char*) "Main", 300, NULL, Default_TASK_PRIORITY, NULL);

/* Finally start the scheduler. */
vTaskStartScheduler();

/* Will only reach here if there is insufficient heap available to start
the scheduler. */

while(1);
return 0;
}

//--------
void MainTask( void *pvParameters )
{
for( ;; )
{
vTaskDelay(10); //--->>> Crash!
Nop();
Nop();
};
};

“I want to port a project from dsPIC33F to dsPIC33EP256MU810. ”

As you found out, EDS is not currently supported on the dsPIC. It is supported on PIC24, and there was a reason why the same support was not extended to the dsPIC but to be honest I can't quite remember what it was - something to do with additional registers being required though.

“I declared MPLAB_DSPIC_PORT”

That is actually not necessary - the old definitions are maintained in portable.h for backward compatibility with ancient projects (including the demos in the FreeRTOS download - although V7.5.0 has MPLAB X projects for the PIC24 and dsPIC). It won't do any harm defining it, but its just easier to not define in and instead make sure the correct path is included in your IDEs include path. That is, the path to the correct portmacro.h header file in FreeRTOS/source/portable/MPLAB/...

“Same Project compiled for dsPIC33FJ128MC804 does work fine.”

So that is good...but does not necessarily prove it is working correctly unless you have tired all combinations of placement to ensure the EDS extensions are being exercised.

“As my knowledge ends at this point I want to ask you to check this behavior.”

Sorry - can't do that right now, especially as this is your own code rather than supported code. However, I can confirm that yes, there was a problem expected...somewhere.

If you sort this out please be sure to post your work to the FreeRTOS Interactive site. Maybe you will be lucky and somebody else reading this post will have this working already.

Regards.

Dear RichardBarry,

thanks for your fast reply.

if MPLAB_DSPIC_PORT is not declared, the compiler will fail to find "portRESTORE_CONTEXT()". I can find this Macro in the source only within the defines of MPLAB_DSPIC_PORT.

“
I can't quite remember what it was - something to do with additional registers being required though.”

Could it be that the DO Stack was the Problem as there is a Stack with four places now for DO Loops?

“especially as this is your own code rather than supported code. ”

Well my code actually rather consists of a Main Task with an endless loop including a vTaskDelay(10); and the suggested RTOS init. Nothing else. I also tried your Demo Projects with similar modification and same result.

The Question is now, will dsPic33e Family be supported in the near future or would I have to change to another RTOS?

Is there a way to get more support regarding this matter if buying kind of professional Support Ticket or what ever?

Best regards

Heiko

“if MPLAB_DSPIC_PORT is not declared, the compiler will fail to find "portRESTORE_CONTEXT()". ”

You are right. I forgot that. It has been fixed in V7.5.0 (I think).

“Could it be that the DO Stack was the Problem as there is a Stack with four places now for DO Loops?”

Probably.

“will dsPic33e Family be supported in the near future”

In the very near future no - in the longer term I can't say for definite as it will depend on demand.

I will come back to you on that last point.

Regards.

Richard,

you mentioned Version 7.5.0. coming up.
When will this be relaesed, do you have a prerelease version for tests?

Best

Heiko

It will be released as soon as I have updated the documentation - in the mean time you can get it out of SVN. It is currently the head revision and will be tagged when the zip files are released (see the "Code" menu item at the top of the SourceForge page when you are viewing this form).

If all goes well today then the .zip files may get uploaded this afternoon.

Regards.

Richard,

hello again. please refer to following discussion, solving for the moment the problems I had . https://sourceforge.net/p/freertos/discussion/382005/thread/9df19af7/

best regards Heiko