There are some differences between dsPIC33FJ512GP710 and the dsPIC33EP512MU810 e.g. the way memory is handled. GP710 has tables with PSVPAG register and MU810 has pages with DSRPAG and DSWPAG.
In portasm_dsPIC.s and port.c can I simply replace PSVPAG with DSRPAG? Any other changes I should make to port the RTOS to the new chip?
In addition to changing PSVPAG to DSRPAG, you really should add an identical line for DSWPAG (and do this twice in port.c and twice in portasm_dsPIC.S). Note that the PUSHes and POPs should be in reverse order after you add the line. I’m not sure why these changes haven’t been added to the distribution yet. It’s been several years since the first parts with the EDS came out (e.g. the PIC24FJ256DA210). I suspect two new versions would be required: one for the PIC24 DA210 and PIC24 EP parts, and one for the 33F EP parts, which include the EDS and dsPIC core registers.
Thanks Nathan. I made the changes, but not sure if that worked or not. The demo app keeps halting and when I single step, I see that malloc ran out of space even at 5120 bytes. Doesn’t seem right. I even removed LCD tasks.
It compiles ok, but the problem is that using the simulator I’m having a error saying: CORE-E0004: Trap due to unimplemented FLASH memory access, occurred from instruction at 0x001370
This happens after passing the line:
asm volatile( “return” );
on portBASE_TYPE xPortStartScheduler( void )
I’m sure that the previous line, portRESTORE_CONTEXT, is causing this issue, since is where I substituted PSVPAG for the other 2 registers, and for some reason, the PC gets corrupted after this restore context
What seems to be the problem ? I have inverted the order in which i push and pop registers DSWPAG and DSRPAG.
Can you post your port of FreeRTOS on pics that have EDS ?
It might happen because of a mishandled pointer. With the EP devices, the first address bit is not used for addressing. You can find more details here: http://www.microchip.com/forums/m698417.aspx