PIC32MX Noob in need of some help

[MAntunes]

Hi guys,

I recently got the Microstick II from Microchip in order to learn how to program PIC32MX microcontrollers.
I have some experience with PIC24F.

When I started learning how to program the PIC24F my professor gave me a configuration file that worked beautifully every time but know I'm trying to write my own for the PIC32MX250F128B and I'm having some difficulties.

In attachment is my current configuration file. I want the PIC32MX working at 40MHz.
The configuration bits that are commented are the ones I don't know how to configure. Could you give some help?

Another thing I wanted to ask you is if the SYSTEMConfigPerformance() or SYSTEMConfig() functions are really needed. I want to avoid using the Peripheral Library as I never used I with the PIC24F.

Also, if you can point me to some tutorials and examples for this microcontroller I would be very grateful.
Thank you in advance,
Miguel

Thank you very much in advance.

[mikeselectricstuff]

Here are settings for 24, 40 and 40MHz

Code: [Select]


#define clockfreq 40
#if clockfreq==24
#pragma config FPLLMUL = MUL_24, FPLLIDIV = DIV_2, FPLLODIV = DIV_4 //
#define clk 1
#endif
#if clockfreq==40
#pragma config FPLLMUL = MUL_20, FPLLIDIV = DIV_2, FPLLODIV = DIV_2 //
#define clk 1
#endif
#if clockfreq==48
#pragma config FPLLMUL = MUL_24, FPLLIDIV = DIV_2, FPLLODIV = DIV_2//
#define clk 1
#endif
#ifndef clk
#error undefined clock
#endif

#pragma config FWDTEN = ON,WDTPS = PS2048,WINDIS=OFF // 2048=2 secs WDT
#pragma config  FNOSC = FRCPLL, FPBDIV = DIV_1,FSOSCEN=OFF,FCKSM=CSECME
#pragma config JTAGEN = OFF,OSCIOFNC=OFF
#pragma config IOL1WAY=OFF,PMDL1WAY=OFF


[Howardlong]

For PIC32MX2xx and 1xx, there is no wait state requirement or cache, and the peripheral clocks can run at system clock speed, so it’s not unusual to go bare metal.

You should be able to get your device up and running with an absolute minimum of code.

Code: [Select]

#pragma config FPLLIDIV = DIV_2         // PLL Input Divider (2x Divider)
#pragma config FPLLMUL = MUL_20         // PLL Multiplier (20x Multiplier)
#pragma config FPLLODIV = DIV_2         // System PLL Output Clock Divider (PLL Divide by 2)
#pragma config FNOSC = FRCPLL           // Oscillator Selection Bits (Fast RC Osc with PLL)

// 40MHz on pin 10
#pragma config OSCIOFNC = ON            // CLKO Output Signal Active on the OSCO Pin (Enabled)
#pragma config FPBDIV = DIV_1           // Peripheral Clock Divisor (Pb_Clk is Sys_Clk/1)
#pragma config FWDTEN = OFF             // Watchdog Timer Enable (WDT Disabled (SWDTEN Bit Controls))
#pragma config JTAGEN = OFF             // JTAG Enable (JTAG Disabled)

// Microstick II debug switch position A
#pragma config ICESEL = ICS_PGx1        // ICE/ICD Comm Channel Select (Communicate on PGEC1/PGED1)

#include <xc.h>
#define FCY 40000000

void main(void)
{
    TRISAbits.TRISA0=0;
   
    // 4MHz toggle (5 instruction cycles/phase)
    while (1)
    {
        LATAINV=1;
    }
    return;
}



[mikeselectricstuff]

For PIC32MX2xx and 1xx, there is no wait state requirement or cache, and the peripheral clocks can run at system clock speed, so it’s not unusual to go bare metal.

That's no longer strictly true since introduction of the new 80MHz 32MX174  - with this part you do need to set up flash wait states.
This caught me out as I'd not used the bigger MX parts so didn't think to look for anything to do with flash speed.

[Howardlong]

For PIC32MX2xx and 1xx, there is no wait state requirement or cache, and the peripheral clocks can run at system clock speed, so it’s not unusual to go bare metal.

That's no longer strictly true since introduction of the new 80MHz 32MX174  - with this part you do need to set up flash wait states.
This caught me out as I'd not used the bigger MX parts so didn't think to look for anything to do with flash speed.

Good point, and I was thinking that between writing the email and testing the code above, it promptly dropped out of my FIFO.

[ggchab]

Is there any reason for not using the MCC code configurator ? I am learning the dsPIC33EV256GM002 and this seems to be very powerful to create the initialisation code.

[Howardlong]

Is there any reason for not using the MCC code configurator ? I am learning the dsPIC33EV256GM002 and this seems to be very powerful to create the initialisation code.

Where to start? ;-)

I am sure there will be other opinions.

I had high hopes for MCC, I used it at the start for a few projects but I lost patience with it, and so here are my issues with MCC...

o It's very buggy: do you really want to be trying to debug and patch machine-generated code?
o It makes it very difficult to maintain code:
---the generated code is not properly segregated from user code;
---it's too easy to accidentally wipe your own code when you need to make changes;
---the peripheral register bit fields aren't properly documented by the generated code;
---maintenance between versions of MCC is very problematic, and there are very frequent releases.
o You still need to know at a hardware and register level how each non-complex peripheral works anyway, so MCC is just something extra you have to learn how to use.
o You are forced into a directory and file structure dreamt up by the guy who wrote it, it's unlikely to be a structure you'll like.
o The generated code for non-complex peripherals is not built for performance, it's built for generic use.
o The generated code for non-complex peripherals is over-complicated for most implementations.

The only reason I'd use MCC now is for complex peripherals like USB. Everything else I'm bare metal, and use and write my own libraries that are fit for purpose. While you'll apparently be able to get a blinky going from scratch quite quickly (although I bet I'd be able to hand code it quicker), anything with any non-trivial application that needs maintaining, and is built incrementally rather than top-down, will be very difficult.

In short, for non-complex peripherals, MCC is merely a crutch that might appear to get you started quickly, but I guarantee that you'll lose patience with it if you're doing anything serious. It is not a replacement for reading a device's data sheet and its errata, in fact it's something extra you have to deal with, I think unnecessarily. If its code quality were better and you could be sure of being able to help you maintain code without it overwriting your own, I might feel better about it!

[mikeselectricstuff]

Is there any reason for not using the MCC code configurator ? I am learning the dsPIC33EV256GM002 and this seems to be very powerful to create the initialisation code.

Where to start? ;-)

I think the only sensible way to use this sort of thing is to use it as a starting point to get the initial settings, which you then use and tweak as necessary, without going near the tool again.
Even then it may create unnecessary stuff or not be quite what you need.

After you've taken the generated code and done your own thing with it, the tool can't possibly know what you want to do, so re-generating is very risky.

And you can probably pretty much get the same by looking at some example applications.
Your time is likely to be  better spent understanding the hardware better.
 

[ggchab]

Thank you for these very interesting tips. This is the first time I program a PIC in C (until now, I used assembler only for PIC 12F, 16F and 18F) and I found the code generated by MCC useful. I will follow your advice and only use it as a starting point.

[Howardlong]

Thank you for these very interesting tips. This is the first time I program a PIC in C (until now, I used assembler only for PIC 12F, 16F and 18F) and I found the code generated by MCC useful. I will follow your advice and only use it as a starting point.

If you were programming PICs in assembly language before, I can only imagine that MCC will get in your way!

[ggchab]

Yes. As if I was losing the control ...

[MAntunes]

Thank you very much.
I've been able to make my first program work, a simple LED blinky with a button.
I have to read more about the SYSTEMConfigPerformance() function and how it works and do some experiments with and without it. This function does not even come included in the new version of the XC32 compiler so I would like to have my way arround it.

I've also started reading the book "Programming 32-bit Microcontrollers in C - Exploring the PIC32" and it seems pretty good.

Any more recommendations from you?

[Howardlong]

The di Jasio book is a bit old now, but it is at least mostly bare metal as I remember it.

The Microchip “way” nowadays for PIC32 is Harmony or MCC for the bottom end. Unless you are using USB. Ethernet, or Wifi, I’d ignore these framework/code generators and go bare metal, they just get in your way on any serious project.

For USB, for the MX230/250/270 at least, you can still use the legacy MLA, although I am minded to suggest you probably should be going to Harmony nowadays. Be aware that learning Harmony is a significant investment in effort, but then so is the MLA, just in a different way. Myself, I only use Harmony to get access to the complex peripherals like USB and the tcp/ip stack, the rest I do as bare metal.

There is no harm in having multiple XC32 verisons and their header/lib files installed either if you require them, they generally don’t interfere with each other in my experience. XC32 as a compiler has been pretty reliable, except for the pro licensing, which continues to occasionally break and frustrate!

[mikeselectricstuff]

For USB, for the MX230/250/270 at least, you can still use the legacy MLA, although I am minded to suggest you probably should be going to Harmony nowadays. Be aware that learning Harmony is a significant investment in effort, but then so is the MLA, just in a different way. Myself, I only use Harmony to get access to the complex peripherals like USB and the tcp/ip stack, the rest I do as bare metal.

I've used MLA for USB and  SD card filesystems & it was pretty simple - I just took one of their demos, stripped out the bits I didn't need and copied the required source files into my project.
I think the way they set it up by default is to have your project pull the MLA files from a common MLA folder, but that's pretty stupid as it's bound to break something if it gets updated.

[JPortici]

Is there any reason for not using the MCC code configurator ? I am learning the dsPIC33EV256GM002 and this seems to be very powerful to create the initialisation code.

the only reason one should use MCC is to lay out the pin mapping... (the communication stacks too, that's code you want to "just work")

and of course the bigger parts where this is would really be a blessing are not supported.. i had to manually laiy out 141 out of 144 pins of the MU814 (well counting the power pins too) because it's not supported in MCC.

dsPICs are simple, just a couple of registers per peripheral and no stupid hardware bugs (like non functional I2C so it has to be done in software)
no need to add layers of obfuscation through bloated libraries

[MAntunes]

For PIC32MX2xx and 1xx, there is no wait state requirement or cache, and the peripheral clocks can run at system clock speed, so it’s not unusual to go bare metal.

That's no longer strictly true since introduction of the new 80MHz 32MX174  - with this part you do need to set up flash wait states.
This caught me out as I'd not used the bigger MX parts so didn't think to look for anything to do with flash speed.

So with my PIC32MX250F128B I don't need to configure any of that?

[mikeselectricstuff]

For PIC32MX2xx and 1xx, there is no wait state requirement or cache, and the peripheral clocks can run at system clock speed, so it’s not unusual to go bare metal.

That's no longer strictly true since introduction of the new 80MHz 32MX174  - with this part you do need to set up flash wait states.
This caught me out as I'd not used the bigger MX parts so didn't think to look for anything to do with flash speed.

So with my PIC32MX250F128B I don't need to configure any of that?

No. with the right config fuse setting you're ready to go at full speed without touching any oscillator configs.

[MAntunes]

For PIC32MX2xx and 1xx, there is no wait state requirement or cache, and the peripheral clocks can run at system clock speed, so it’s not unusual to go bare metal.

That's no longer strictly true since introduction of the new 80MHz 32MX174  - with this part you do need to set up flash wait states.
This caught me out as I'd not used the bigger MX parts so didn't think to look for anything to do with flash speed.

So with my PIC32MX250F128B I don't need to configure any of that?

No. with the right config fuse setting you're ready to go at full speed without touching any oscillator configs.

Right now I'm using the configurations you put gave me.
How can I know if it's running at full speed?

[JPortici]

set up a timer so that you have an interrupt every "x" milliseconds and blink a LED. verify it takes "x" milliseconds

Set up a PWM module so that it produces a square wave of a certain frequency. measure that frequency

set up the reference clock output to provide a known division of the system clock and measure it

[mikeselectricstuff]

For PIC32MX2xx and 1xx, there is no wait state requirement or cache, and the peripheral clocks can run at system clock speed, so it’s not unusual to go bare metal.

That's no longer strictly true since introduction of the new 80MHz 32MX174  - with this part you do need to set up flash wait states.
This caught me out as I'd not used the bigger MX parts so didn't think to look for anything to do with flash speed.

So with my PIC32MX250F128B I don't need to configure any of that?

No. with the right config fuse setting you're ready to go at full speed without touching any oscillator configs.

Right now I'm using the configurations you put gave me.
How can I know if it's running at full speed?

You can change the OSCIOFNC setting to send the clock out of a pin
Or set up a timer with a known prescale and reload value an output a pin when it rolls
Or Set up a UART  and check that the output is at the expected baudrate
Or Because I said it was known working set of configs...
 

[Howardlong]

Look at these two lines in my code:

Code: [Select]

// 40MHz on pin 10
#pragma config OSCIOFNC = ON            // CLKO Output Signal Active on the OSCO Pin (Enabled)

I tend to put the clock on the CLKO pin if I can (e.g., not using the pin for a crystal) as a matter of course.

Also look at these lines in my code:

Code: [Select]

    TRISAbits.TRISA0=0;
   
    // 4MHz toggle (5 instruction cycles/phase)
    while (1)
    {
        LATAINV=1;
    }

Now you wouldn't leave this in your code, but you can use it as a quick and dirty way to determine if your oscillator is running as expected by probing RA0. This works well for this chip, but be aware that if you have wait states or the peripheral bus isn't running at the system clock frequency, results will be skewed. In the example I gave, the configs have the peripheral bus is running at the system clock frequency and there are no wait states. For higher end PIC32, this likely won't be the case.

[mikeselectricstuff]

Look at these two lines in my code:

Code: [Select]

// 40MHz on pin 10
#pragma config OSCIOFNC = ON            // CLKO Output Signal Active on the OSCO Pin (Enabled)

I tend to put the clock on the CLKO pin if I can (e.g., not using the pin for a crystal) as a matter of course.

Also look at these lines in my code:

Code: [Select]

    TRISAbits.TRISA0=0;
   
    // 4MHz toggle (5 instruction cycles/phase)
    while (1)
    {
        LATAINV=1;
    }

Now you wouldn't leave this in your code, but you can use it as a quick and dirty way to determine if your oscillator is running as expected by probing RA0. This works well for this chip, but be aware that if you have wait states or the peripheral bus isn't running at the system clock frequency, results will be skewed. In the example I gave, the configs have the peripheral bus is running at the system clock frequency and there are no wait states. For higher end PIC32, this likely won't be the case.

It's always a bit dangerous to rely on instruction timings on an unfamiliar chips due to the issues you mention - unless you;re comparing to other chips you don't have a reference for how fast it should be running.
Also, it's probably more reliable to do something like
LATAINV=1;
LATAINV=1;
LATAINV=1;
LATAINV=1;
in a loop to avoid any  confusion caused by how the compiler deals with loops.
If you see pulses that are 1/48uS long on a part you expect to be running 48MHz then you know it's right ( thought the opposite is not necessarily true due to possible waitsates, peripheral bus clocks etc.)
Timers or other peripherals are more reliable, as long as you understand how their clock source works relative to the CPU.
When I started playing with the 80MHz 32MX174 I got really confused as the peripherals were giving the speed I expected but the CPU was runnig exactly 8x slower compared to a '170- turned out this was due to flash waitstates, , which I'd not enountered before as I'd only used the '1x0 devices previously. Definitely something they should highlight in the datasheet!

[MAntunes]

Thank you very much!
So, with the timers and PWM I can test the peripheral speed, right? And what about the CPU speed? Toggling the GPIO in a loop can tell me the CPU speed?

When I started playing with the 80MHz 32MX174 I got really confused as the peripherals were giving the speed I expected but the CPU was runnig exactly 8x slower compared to a '170- turned out this was due to flash waitstates, , which I'd not enountered before as I'd only used the '1x0 devices previously. Definitely something they should highlight in the datasheet!

How did you work arround this? Using the peripheral library?

[mikeselectricstuff]

Thank you very much!
So, with the timers and PWM I can test the peripheral speed, right? And what about the CPU speed? Toggling the GPIO in a loop can tell me the CPU speed?

When I started playing with the 80MHz 32MX174 I got really confused as the peripherals were giving the speed I expected but the CPU was runnig exactly 8x slower compared to a '170- turned out this was due to flash waitstates, , which I'd not enountered before as I'd only used the '1x0 devices previously. Definitely something they should highlight in the datasheet!

How did you work arround this? Using the peripheral library?

No I just read the appropriate part of the datasheet.

[MAntunes]

No I just read the appropriate part of the datasheet.

Thank you very much. If I have any questions regarding this I'll ask here.

Another question: do I need to define any kind of frequency macro? Like

Code: [Select]

#define FCY 40000000 or something similar or I only need to configure the "fuses" the right way?