Helpful ReplyHot!Porting from PIC32MX to PIC32MZ

Page: 123 > Showing page 1 of 3
Author
alex_elec
Junior Member
  • Total Posts : 94
  • Reward points : 0
  • Joined: 2014/03/26 04:41:13
  • Location: UK
  • Status: offline
2017/02/08 03:03:35 (permalink)
0

Porting from PIC32MX to PIC32MZ

Hi peeps.
 
I posted on here a while back about changing my uP solution from a PIC32MX to the MZ to help solve some graphics issues I was having (running a QVGA screen direct from the MX and not using a controller). The thread was locked so I'm posting again
 
We're biting the bullet and designing in the PIC32MZ1024EFE100 in place of the PIC32MX695F512L
 
Currently the project is compiling with XC32(v1.34) with a few plib dependencies. I haven't used harmony yet and don't really want to with the MZ. In the compiler release notes it says v1.34 does support the MZ series so hopefully I can just use all my current driver code for the uarts, internal ADC, bit bashed I2C?
 
I'll be compiling the project with the target device as the new MZ one this week to check if it compiles and to hopefully fix anything before I get the hardware as we won't be seeing the new PCBs for at least a few weeks.
 
Has anyone had any issues with the MZ with earlier versions of the XC32 compiler? A broad question I know, but just wondered if there were any showstoppers straight away
 
Thanks,
Alex
 
#1
Mysil
Super Member
  • Total Posts : 2917
  • Reward points : 0
  • Joined: 2012/07/01 04:19:50
  • Location: Norway
  • Status: offline
Re: Porting from PIC32MX to PIC32MZ 2017/02/08 03:51:13 (permalink)
3 (1)
Hi,
I have not yet used  PIC32MZ, so do not have actual experience.
Why are you still using XC32 v1.34 ? the current compiler release for PIC32 devices is v1.42.
 
Looking into the compiler installation directories for version 1.34,
there is no device support file for your PIC32MZ1024EFE100
device among the processor include files, so I think 1.34 will not work for your MZ EFE100.
 
For the file:  \v1.42\pic32mx\include\proc\p32mz1024efe100.h
there are a heap of differences from the corresponding files in version v1.40 and v1.42.
 
Regards,
   Mysil
#2
simong123
Lab Member No. 003
  • Total Posts : 1283
  • Reward points : 0
  • Joined: 2012/02/07 18:21:03
  • Location: Future Gadget Lab (UK Branch)
  • Status: offline
Re: Porting from PIC32MX to PIC32MZ 2017/02/08 07:12:06 (permalink)
0
MysilLooking into the compiler installation directories for version 1.34,
there is no device support file for your PIC32MZ1024EFE100
device among the processor include files, so I think 1.34 will not work for your MZ EFE100.
 
For the file:  \v1.42\pic32mx\include\proc\p32mz1024efe100.h
there are a heap of differences from the corresponding files in version v1.40 and v1.42.
 
Regards,
   Mysil

You could maybe add the 1.42 part support patch to 1.34, but you will need 1.42 if you want to use the FPU. I would recommend going straight to 1.42, (and the next version if you use FP, said to be many FP library fixes).
 
Note the ADC on the MZ....EF is very different to that on the MX. The UART is identical (I think), and bit-banged I2C is whatever you want it to be...
#3
alex_elec
Junior Member
  • Total Posts : 94
  • Reward points : 0
  • Joined: 2014/03/26 04:41:13
  • Location: UK
  • Status: offline
Re: Porting from PIC32MX to PIC32MZ 2017/02/08 09:24:40 (permalink)
0
Thanks for the info
 
So, my plib calls/use of it's defines etc.. will they still be ok for v1.42? Or will I need to re-write some of these using the harmony based ones?
 
Decent floating point support will be useful. I'll upgrade to the latest compiler tomorrow for my MX code and see how I go
 
Then I'll change the target device to the MZ part and hopefully have a smooth transition.
 
Will keep updating the thread
#4
NKurzman
A Guy on the Net
  • Total Posts : 16680
  • Reward points : 0
  • Joined: 2008/01/16 19:33:48
  • Location: 0
  • Status: online
Re: Porting from PIC32MX to PIC32MZ 2017/02/08 09:47:28 (permalink)
3 (1)
plib does not support the MZ. You would need to write all the calls.
You may want to look in to making a skeleton Harmony project and put your code inside it.
#5
Mysil
Super Member
  • Total Posts : 2917
  • Reward points : 0
  • Joined: 2012/07/01 04:19:50
  • Location: Norway
  • Status: offline
Re: Porting from PIC32MX to PIC32MZ 2017/02/08 12:44:30 (permalink)
4.25 (4)
Hi,
Many of the peripherals are very similar between PIC32MX and PIC32MZ.
For those  peripherals, I would rather suggest that  you stay away from Harmony,
and instead port the code you have to PIC32MZ.
Where you have used functions or macros in Plib, you may look into what the functions actually do,
and bring the needed pieces of source code into your own directories, or replace with direct register access,
using structure names, or register and field names defined in the device support files: <xc.h> and  \v1.42\pic32mx\include\proc\p32mz1024efe100.h
 
You may do most of those modifications on your existing PIC32MX platform.
 
Do not include the device specific file in your program directly, use <xc.h> as before,
but studying the device support file together with device datasheet, help to understand what synbol names are available. The device file correspond closely to the datasheet.
 
There exists a peripheral layer of hardware access functions in Harmony.
They are Not a compatible replacement for Plib functions you may have used.
Harmony peripheral layer define their own abstraction of the hardware, that is completely different from anything you recognize, and do Not correspond with the datasheet.
Harmony peripheral layer bring no benefit by itself. It is only useful when used as basis for Harmony drivers and system service functions. 
 
 
Oscillator setup is different, and Interrupt handling is different between PIC32MX and PIC32MZ devices.
In MZ, there are no interrupt vector array in flash program memory.
Instead, the interrupt controller have ISR addresses in registers, so avoid one layer of flash memory access.
There is a separate ISR vector register for every interrupt request bit.
this have been used to remove the table of interrupt request symbol names from PIC32MZ device file.
There is only one list of Interrupt Vector defines,  _UART1_RX_VECTOR,  _UART1_TX_VECTOR and  _UART1_FAULT_VECTOR 
symbols like  _UART1_TX_IRQ,  _UART1_RX_IRQ,  _UART1_ERR_IRQ  and  _UART_1_VECTOR
are not defined for MZ devices.
You may eventually define your own translations, instead of changing all source to be different for MX and MZ.
 
Since number and ordering of interrupt sources are different, IFS1, IEC1, IFSx and IECx numbering do not match.
You will need to handle the differences,
or you may do something like this:

/*******************************************************************************
 *    Set Interrupt Enable Control register bit with IRQ number argument.
 */
INLINE_API
void IECxEnable (int IRQ )
{
    unsigned int ireg = IRQ >> 5;        /* Shift to isolate register number. */
    unsigned int ibit = IRQ & 0x001F;    /* 5 Low order bits is bit number in register. */
volatile unsigned int *addr;
     addr = &IEC0 + ireg * 4 + 2;        /* Pointer to IECxSET register. */
    *addr = 1 << ibit;
}
 
/*******************************************************************************
 *    Clear a bit in Interrupt Flag Status register.
 *    argument is IRQ number as defined in Device support file,
 *  or Interrupt VECTOR number on MZ.
 */
INLINE_API
void IFSxClear (int IRQ )
{
    unsigned int ireg = IRQ >> 5;        /* Shift to isolate register number. */
    unsigned int ibit = IRQ & 0x001F;    /* 5 Low order bits is bit number in register. */
volatile unsigned int *addr;
     addr = &IFS0 + ireg * 4 + 1;        /* Pointer to IFSxCLR register. */
    *addr = 1 << ibit;
    return;
}  

Compile these functions with inline and optimization, compiler should optimize most of the code, since the argument will mostly be a defined constant from the device file.
 
Regards,
   Mysil
 
 
 
 
#6
alex_elec
Junior Member
  • Total Posts : 94
  • Reward points : 0
  • Joined: 2014/03/26 04:41:13
  • Location: UK
  • Status: offline
Re: Porting from PIC32MX to PIC32MZ 2017/03/28 08:31:32 (permalink)
0
Thanks for all the info on this. I've started today to eliminate my dependency on the plib for my PIC32MX project before porting to the MZ so hopefully most of the register calls will smoothly migrate.
 
Not sure how to write the interrupt handlers though, just removing #include <plib.h> 
affects my DMA handler, which is:
 
void __ISR(_DMA1_VECTOR, ipl7SRS) DmaHandler1(void)
{

}

 
Errors are:
../Source/GraphicsDriver.c:245:12: error: expected declaration specifiers or '...' before numeric constant
../Source/GraphicsDriver.c:245:26: error: expected declaration specifiers or '...' before 'ipl7SRS'
../Source/GraphicsDriver.c: In function '__ISR':
../Source/GraphicsDriver.c:245:35: error: expected declaration specifiers before 'DmaHandler1'
../Source/GraphicsDriver.c:297:1: error: expected '{' at end of input
 
Anyway to set up this ISR just using #include <xc.h>
 
Thanks!
 
post edited by alex_elec - 2017/03/28 08:34:14
#7
malaugh
Super Member
  • Total Posts : 352
  • Reward points : 0
  • Joined: 2011/03/31 14:04:42
  • Location: San Diego
  • Status: offline
Re: Porting from PIC32MX to PIC32MZ 2017/03/28 10:35:30 (permalink)
5 (1)
We also ported MX code to MZ (no Harmony), ISR translation is
 
void __attribute__((vector(_DMA1_VECTOR), interrupt(IPL4SRS), optimize("-fno-shrink-wrap"), nomicromips)) DmaHandler1(void)
 
 
#8
alex_elec
Junior Member
  • Total Posts : 94
  • Reward points : 0
  • Joined: 2014/03/26 04:41:13
  • Location: UK
  • Status: offline
Re: Porting from PIC32MX to PIC32MZ 2017/03/29 00:26:37 (permalink)
3 (1)
malaugh
We also ported MX code to MZ (no Harmony), ISR translation is
 
void __attribute__((vector(_DMA1_VECTOR), interrupt(IPL4SRS), optimize("-fno-shrink-wrap"), nomicromips)) DmaHandler1(void)
 
 


Excellent, thanks very much
 
Now I'm having some fun with the RTC libraries :D
 
I'll keep updating my progress here as it might be useful for people
#9
alex_elec
Junior Member
  • Total Posts : 94
  • Reward points : 0
  • Joined: 2014/03/26 04:41:13
  • Location: UK
  • Status: offline
Re: Porting from PIC32MX to PIC32MZ 2017/03/29 03:51:20 (permalink)
0
Have somehow broken functionality of my code...still using XC32v1.34, but have removed all plib dependencies and it's compiling ok
 
Now though, I'm getting stuck somewhere with the debugger reporting:
 
No source code lines were found at current PC 0xbfc00000
 
I'm probably not handling an interrupt correctly? Can't remember how to check the status reg that says which vector was at fault...
post edited by alex_elec - 2017/03/29 04:11:25
#10
Mysil
Super Member
  • Total Posts : 2917
  • Reward points : 0
  • Joined: 2012/07/01 04:19:50
  • Location: Norway
  • Status: offline
Re: Porting from PIC32MX to PIC32MZ 2017/03/29 14:37:15 (permalink)
4 (1)
Hi,
Address 0xBFC00000 is the start address of Boot Flash Memory. It is the Reset address where the CPU Start after a Reset, when you start the program in Debugger, or when Power On.
It is the beginning of C Runtime Startup Code, which is normally loaded from a object library archive file,
without access to source code, so 'No source code lines were found...' is as should be expected.
 
Do you get this when starting debugger, or after trying to run?
If you get there after runnng some, there have been a crash that have caused a reset.
Examine RCON register, it have mostly status bits.
 
Then install Exception Handlers with source code in your program, such that you may set a breakpoint, and stop before the processor Reset, and information get lost.
 
There is source code for default handlers in compiler installation directories, somewhere like:
C:/program files(x86)/Microchip/xc32/v1.42/pic32-libs/libpic32/default_vector_dispatch/defaultinterrupt.c
C:/program files(x86)/Microchip/xc32/v1.42/pic32-libs/libpic32/startup/...
C:/program files(x86)/Microchip/xc32/v1.42/pic32-libs/libpic32/stubs/...
Source code for C Runtime Startup,  is in:
C:/program files(x86)/Microchip/xc32/v1.42/pic32-libs/libpic32/startup/crt0.S
it is a piece of assembler source code.
 
Regards,
   Mysil
 
#11
alex_elec
Junior Member
  • Total Posts : 94
  • Reward points : 0
  • Joined: 2014/03/26 04:41:13
  • Location: UK
  • Status: offline
Re: Porting from PIC32MX to PIC32MZ 2017/03/30 01:41:50 (permalink)
3 (1)
Thanks Mysil, 
 
Yes I've been using the EPC register to see where in my code it has been failing.
 
To recap, to remove my PLIB dependencies, I have changed my ISR routines to not use the __ISR macro and use a standard prototype:
 
//void __ISR(_OUTPUT_COMPARE_3_VECTOR, IPL1AUTO) OutputCompare3Interrupt(void)
void __attribute__((vector(_OUTPUT_COMPARE_3_VECTOR), interrupt(IPL1SRS), optimize("-fno-shrink-wrap"), nomicromips)) OutputCompare3Interrupt(void)

 
Is there an easy way of replicating the SYSTEMConfigPerformance(80000000); call?
 
I've broken it down to this:
 

    cache_status = CHECON;
    cache_status |= (3 << 0x00000004); //was #define CHE_CONF_PF_ALL (3 << _CHECON_PREFEN_POSITION) - _CHECON_PREFEN_POSITION 0x00000004
    CHECON = cache_status;
    CheckCheKseg0CacheOn(); //This routine is used to enable cacheability of KSEG0.

 
Where CheckCheKseg0CacheOn is basically a local copy of that function:
 
void __attribute__ ((nomips16)) CheckCheKseg0CacheOn()
{
 register unsigned long tmp;
 asm("mfc0 %0,$16,0" : "=r"(tmp));
 tmp = (tmp & ~7) | 3;
 asm("mtc0 %0,$16,0" :: "r" (tmp));
}

 
But somewhere I'm still going wrong. 
 
I've also used this define in place of the library call:
 

#define ReadCoreTimer() _CP0_GET_COUNT() // Read the MIPS Core Timer

#12
simong123
Lab Member No. 003
  • Total Posts : 1283
  • Reward points : 0
  • Joined: 2012/02/07 18:21:03
  • Location: Future Gadget Lab (UK Branch)
  • Status: offline
Re: Porting from PIC32MX to PIC32MZ 2017/03/30 06:10:59 (permalink)
0
1. You don't need to change from using the __ISR() macro. Just include "sys/attribs.h", where it is defined (I don't now why "xc.h" doesn't include this by default).
2. You are using the SRS registers, but are you setting up PRISS? It defaults to 0, which means in multi-vector mode all interrupts share the same shadow register set (SS0), and in single vector mode the interrupt is not presented with a shadow regester set. I use 0x76543210.
3. You don't need to enable the cache. The default startup code does this for you.
4. You need to setup PRECON to enable pre-fetch, and set the correct flash wait states for your machine. The values for the wait states are in table 37-13 in the datasheet.
#13
Mysil
Super Member
  • Total Posts : 2917
  • Reward points : 0
  • Joined: 2012/07/01 04:19:50
  • Location: Norway
  • Status: offline
Re: Porting from PIC32MX to PIC32MZ 2017/03/30 06:51:38 (permalink)
0
Hi,
I cannot see what reason there may be for your problem.
Since you have removed dependencies on Plib functions and macros,
you may go into 'Project Properties', select the Linker branch, and remove the Tick from 'Link Peripheral Library'
 
__ISR(vector, ipl) macro is not really a Plib dependency, it is a macro provided by the compiler supplied header file:
.../xc32/v1.xx/pic32-libs/include/sys/attribs.h
and may be included by: #include <sys/attribs.h>
but replacing it with __attribute((...)) should be just as good.
The <sys/attribs.h> file, may however have been included by plib.h.
 
Question: What have you done to replace:
    INTEnableSystemMultiVectoredInt();
C runtime startup code do some of the needed settings, but I think you still have to Set MVEC bit in INTCON register, make sure you have somewhere:
    /* Multi-vector setting in INTCON register. */
    INTCONSET = _INTCON_MVEC_MASK;

See attachment with my replacement files for system setup.
SYS_Setup.c and the functions in there is intended to work both on PIC32MX and MZ,
but have not really been tested on PIC32MZ.
 
There are __builtin...(); functions available in the compiler, that may be used instead of INTEnableInterrupts(void);
and some similar functions.
See XC32 Compiler User's Guide.
 
_CP0_GET_COUNT()
is a macro defined in compiler installation system include file:
.../xc32/v1.xx/pic32-libs/pic32-libs/include/cp0defs.h
#include <cp0defs.h>
and should be O.k. to be used both for PIC32MX and PIC32MZ
 
Regards,
   Mysil
#14
alex_elec
Junior Member
  • Total Posts : 94
  • Reward points : 0
  • Joined: 2014/03/26 04:41:13
  • Location: UK
  • Status: offline
Re: Porting from PIC32MX to PIC32MZ 2017/03/30 07:17:18 (permalink)
0
I have it up and running now, my code with XC32v1.34 with no plib dependencies. The problem was the SRS instead of AUTO so yes I think SIMONG was right as I hadn't set up the shadow register set properly.
 
I use:
 
INTCONbits.MVEC = 1; //multi vector mode

 
Which seems to be fine. 
 
Next step is to get the latest compiler working ok, then change my uP to the MZ part to see how it compiles before the boards come in.
 
Thanks for your help!
 
#15
alex_elec
Junior Member
  • Total Posts : 94
  • Reward points : 0
  • Joined: 2014/03/26 04:41:13
  • Location: UK
  • Status: offline
Re: Porting from PIC32MX to PIC32MZ 2017/05/02 08:12:49 (permalink)
0
Hi Guys,
 
I'm back on this - I have a board 30% up and running. Had fun with the oscillator configuration and am doing another PCB spin with MEMs oscillators for POSC and SOSOSC
 
Read the errata about the I2C, I haven't had to alter my code much from the MX version, but I've dropped the bus speed to 100kHz to (hopefully!) overcome the errata. Straight out the box though I'm getting bus collisions even before I call this:
 
I2C4CONbits.SEN=True; // Sending a start

 
I had a work around on the MX to manually set the SCL line high before turning on the I2C module. Does this still apply on the MZ?
 
I'm kinda hoping I don't have to write all my I2C for a bit-bang implementation!
 
#16
simong123
Lab Member No. 003
  • Total Posts : 1283
  • Reward points : 0
  • Joined: 2012/02/07 18:21:03
  • Location: Future Gadget Lab (UK Branch)
  • Status: offline
Re: Porting from PIC32MX to PIC32MZ 2017/05/02 09:49:20 (permalink)
4 (1)
alex_elec
I'm kinda hoping I don't have to write all my I2C for a bit-bang implementation!

Why not?
I haven't used the I2C hardware on any PIC32 since the original MX with it's I2C errata.
It's easy and far more flexible than the hardware.
#17
CinziaG
morite
  • Total Posts : 3144
  • Reward points : 0
  • Joined: 2016/12/07 14:20:36
  • Location: Wien
  • Status: offline
Re: Porting from PIC32MX to PIC32MZ 2017/05/02 10:03:09 (permalink)
0
simong123
 
It's easy and far more flexible than the hardware.




Yep Smile

mi fate schifo, umani di merda.
#18
malaugh
Super Member
  • Total Posts : 352
  • Reward points : 0
  • Joined: 2011/03/31 14:04:42
  • Location: San Diego
  • Status: offline
Re: Porting from PIC32MX to PIC32MZ 2017/05/02 11:10:45 (permalink)
0
alex_elec
I'm kinda hoping I don't have to write all my I2C for a bit-bang implementation!

 
Look at the CPU errata very carefully.  Some I2C peripherals on the MZ work and some don't.  We were using I2C 3 and found it did not work, so we had to bit-bang it.  Also check the CPU clock.  We had to switch to using oscillators because the crystal oscillator circuit in the CPU did not work.
 
There is also some tricks you need to play with the cache to get the MZ working properly.  I cannot remember the details. by there is a quote on "Harmony Hell in a Handbasket" that talks about it.  I could dig it out if no-one else remembers.
 
alex_elec
Hi Simong, back in 2014 a user here on the forums provided me with a pair of files, 'sys_devcon_cache.h' and 'sys_devcon_cache_pic32mz.s' he had rescued from Harmony that contains functions for doing things like flushing and then locking sections of the i cache to make sure critical code is cached.  If these are now distributed with the compiler, that is great, I just wish they had made that sensible choice from day 1 rather than trying to manufacture need.  Unless I am horribly mis-remembering why I went searching for these, they weren't always part of the compiler.

 
#19
malaugh
Super Member
  • Total Posts : 352
  • Reward points : 0
  • Joined: 2011/03/31 14:04:42
  • Location: San Diego
  • Status: offline
Re: Porting from PIC32MX to PIC32MZ 2017/05/02 11:19:12 (permalink)
3 (1)
For What its worth, here is the CPU initialization we use on our projects
 

static void PIC32MZ_CPU_Init(void)
{
    /* Set system cache policy */
    SYS_DEVCON_CacheCoherencySet(SYS_CACHE_WRITEBACK_WRITEALLOCATE);

    /* Flush both I-Cache and D-Cache */
    SYS_DEVCON_CacheFlush();

    DMACON = 0;

    /* Disable global interrupt */
    __builtin_disable_interrupts();

    /* Disable JTAG port */
    CFGCONbits.JTAGEN = 0;

    /* enable predictive prefetch for any address
     * Flash Wait State = 2 */
    PRECONbits.PREFEN = 3;
    PRECONbits.PFMWS = 2;

    /* Unlock */
    SYSKEY = 0x00000000;
    SYSKEY = 0xAA996655;
    SYSKEY = 0x556699AA;

    /* PBCLK8: EBI */
    while (PB8DIVbits.PBDIVRDY == 0);
    PB8DIVbits.PBDIV = 1;
    PB8DIVbits.ON = 1;

    /* PBCLK7: CPU, Deadman Timer */
    while (PB7DIVbits.PBDIVRDY == 0);
    PB7DIVbits.PBDIV = 0;
    PB7DIVbits.ON = 1;

    /* PBCLK5: Flash, Crypto, RNG, USB, CAN, Ethernet, SQI */
    while (PB5DIVbits.PBDIVRDY == 0);
    PB5DIVbits.PBDIV = 1;
    PB5DIVbits.ON = 1;

    /* PBCLK4: Ports */
    while (PB4DIVbits.PBDIVRDY == 0);
    PB4DIVbits.PBDIV = 9;
    PB4DIVbits.ON = 1;

    /* PBCLK3: ADC, Comparator, Timers, Output Compare, Input Capture */
    while (PB3DIVbits.PBDIVRDY == 0);
    PB3DIVbits.PBDIV = 9;
    PB3DIVbits.ON = 1;

    /* PBCLK2: PMP, I2C, UART, SPI */
    while (PB2DIVbits.PBDIVRDY == 0);
    PB2DIVbits.PBDIV = 1;
    PB2DIVbits.ON = 1;

    /* PBCLK1: Always ON */
    while (PB1DIVbits.PBDIVRDY == 0);
    PB1DIVbits.PBDIV = 9;

    /* Configue Reference Clock Outputs */
    REFO1CON = 0;
    REFO2CON = 0;
    REFO3CON = 0;
    REFO4CON = 0;

    RPA14Rbits.RPA14R = 0x5;    /* RPA14 is used by SDO1 */
    SDI1Rbits.SDI1R = 0x2;      /* SDI1 is set to RPF4 */

    /* Lock */
    SYSKEY = 0x33333333;

    /* Configure SRS Priority Selection */
    PRISSbits.SS0 = 0;
    PRISSbits.PRI1SS = 1;
    PRISSbits.PRI2SS = 2;
    PRISSbits.PRI3SS = 3;
    PRISSbits.PRI4SS = 4;
    PRISSbits.PRI5SS = 5;
    PRISSbits.PRI6SS = 6;
    PRISSbits.PRI7SS = 7;

    /* Enable multi vector mode */
    INTCONbits.MVEC = 1;

    /* Enable global interrupt */
    __builtin_mtc0(12, 0, (__builtin_mfc0(12, 0) | 0x0001));
}

#20
Page: 123 > Showing page 1 of 3
Jump to:
© 2018 APG vNext Commercial Version 4.5