Skip to main content
Topic: PIC32 PTH breakout development (Read 11900 times) previous topic - next topic

PIC32 PTH breakout development

[attachment=0]
I received one of the PIC32DIP breakout boards and a PIC32MX220F03B to go with it :D

Now I am a total beginner when it comes to USB so this was my head first dive into it. Since the design for the board called for all Through hole components and some constrains dimensional. (the with of the broken out pins was set at 700mils, thus leaving lots of room on both sides of a standard bread board for wire connections.

Now because of this witch constraint the crystal couldn't be placed as close to the pins as I would have liked. So the first thing I wanted to test on the board was the USB and see if it woks as intended.

To get the most stable result I used a 8Mhz primary harmonic crystal (higher frequency crystals tend to use higher harmonics, and are more prone to noise)

So the first thing I did was try to use the CDC Basic Demo (demo in future use) found in MAL. Easy right.
Wrong. it is only setup for MX4xxx and MX7xxx series of PIC32s. and theses MX1/2xxx use some different configurations.
By just changing the uC used in the demo project resulted in lots of warnings.

So the only thing left was to port it to my uC. I made a new project, and started copying the code that was intended for the 32MX460.chips, and disregarded the rest.

*looking through the code you will stumble onto things like #id defined (__32MX_460***) etc. copied those, spiked all else. Also I spiked including the hardwareprofile.h but copied only the relevant stuff into main.c Skiping all functions that were related to board specific stuff, like LEDs and Swithches.

once I did that, and setup my Configs, the #pragma stuff for my crystal, and lots of browsing to include the relevant header files from MAL into my main.c and usb cdc related .c files. (basically just hitting build and finding the include error and fixing the link)
once all the include errors were fixed the project build successfully. I quickly took my pickit3 and programed the board. stuck the usb jack in and crossed my fingers. And I as greeted with Windows 7 message Unknown device, error 43.

This was annoying as hell since I had no clue what the error could be, as I don't know anything about USB.So I started a thread in Microchips pic32 forum and got a response in 24hs (thanks Hidab).

I used the suggested added configs and added the code to my main.c which he suggested. The one thing that surprised me was that in order for the CDC to work properly USB_POLLING must be defined in usb_config.h instead of USB_INTERRUPT.

Once this was built, and programed, I was warmly surprised by windows finding CDC-RS232 :D:D:D
Below are the configs needed to get it to work with a 8mhz Cristal with the CPU running at 40MHZ

Code: [Select]
        #pragma config UPLLEN    = ON        // USB PLL Enabled
        #pragma config FPLLMUL  = MUL_20        // PLL Multiplier
        #pragma config UPLLIDIV  = DIV_2        // USB PLL Input Divider
        #pragma config FPLLIDIV  = DIV_2        // PLL Input Divider
        #pragma config FPLLODIV  = DIV_2        // PLL Output Divider
        #pragma config FPBDIV    = DIV_1        // Peripheral Clock divisor
        #pragma config FWDTEN    = OFF          // Watchdog Timer
        #pragma config WDTPS    = PS1          // Watchdog Timer Postscale
        #pragma config FCKSM    = CSDCMD        // Clock Switching & Fail Safe Clock Monitor
        #pragma config OSCIOFNC  = OFF          // CLKO Enable
        #pragma config POSCMOD  = HS            // Primary Oscillator
        #pragma config IESO      = OFF          // Internal/External Switch-over
        #pragma config FSOSCEN  = OFF          // Secondary Oscillator Enable (KLO was off)
        #pragma config FNOSC    = PRIPLL        // Oscillator Selection
        #pragma config CP        = OFF          // Code Protect
        #pragma config BWP      = OFF          // Boot Flash Write Protect
        #pragma config PWP      = OFF          // Program Flash Write Protect
        #pragma config ICESEL    = ICS_PGx1      // ICE/ICD Comm Channel Select
        #pragma config DEBUG    = OFF            // Background Debugger Enable
        #pragma config JTAGEN    = OFF            // JTAG Disabled
        #pragma config FUSBIDIO  = OFF
        #pragma config FVBUSONIO = OFF
        #pragma config PMDL1WAY  = OFF
        #pragma config IOL1WAY  = OFF

The following had to be added to the start of the main function, one of things is that the 32mx1/2 series uses ANSEL instead of the AD1PCFG the other 32mxs use

Code: [Select]
    #define CLOCK_FREQ 40000000
    SYSTEMConfig(CLOCK_FREQ, SYS_CFG_WAIT_STATES |  SYS_CFG_PCACHE);
    mJTAGPortEnable(DEBUG_JTAGPORT_OFF);
    INTEnableSystemMultiVectoredInt();
    ANSELA = 0x0000;
    ANSELB = 0x0000;

I'll add the whole project and hex file shortly.
best regards FIlip.


Re: PIC32 PTH breakout development

Reply #2
Bloody hell, that wasn't there two days ago when I was searching for any mx220 usb projects, thanks
best regards FIlip.

Re: PIC32 PTH breakout development

Reply #3
Simply awesome, I was going to ask for this today. I would very much appreciate a demo hex file configured for 20MHz crystal, If you have time, please.  I could use the above HID demo, for my purposes, but I risk not getting the config correct which makes it little difference from what I've already tried.

Re: PIC32 PTH breakout development

Reply #4
@AndThen: What's the point not compiling it yourself?

Re: PIC32 PTH breakout development

Reply #5
Reduced chance of user error.  I haven't taken the time to fully understand the clock math for instance, that is well I thought I understood a few times.. Basically I've gotten it wrong enough times, that I'd like to be spoon fed like a baby.

it is not for a specific project, just a test file for the programmer, so I don't need to care how whatever program works at this point. I was using a simple led blink with the mx110's, which wrote and verified correctly but doesn't blink. Which points back to I don't fully understand the configuration. I'm sure it's my error in the configuration. The blinking codes really hard to mess up, and It flashes as expected if sent via Xferinstruction.

Let me put it clear and short.
I have bricked mx110, by writing bad config data.
Save a poor mx220, donate verified bare metal firmware for my sanity.

PS. I don't think the mx110 is dead just not happy, I likely turned off jtag as well as got wrong clocks, and need to hook up the pickit to the correct serial line.

Re: PIC32 PTH breakout development

Reply #6
@AndThen: You cannot brick the PIC32MX by using wrong config bits. It also accepts the connected PICkit 3 at every available PGEDx/PGECx pair. It just needs to be set correctly it you want to be able to debug the code. The clock/PLL config bits are also only necessary to be correct for *running* your code. Programming supplies its own clock via the PGECx pin.  So in any case, you can reprogram the MCU as often as you like without the possibility of bricking it, so keep trying.

Re: PIC32 PTH breakout development

Reply #7
I'll add the source in a few days tops, as well as the hex files for 4,8,12, and 20Mhz :D I do how ever recommend using the 4 or 8MHz crystal as they are more resistant to noise.  As mentioned above the crystal routing isn't ideal, but it has been confirmed to work in USB CDC. 

I played around with the code, and I am finally getting slightly familiar with USB. I am trying to make it accept 3 operating words through CDC, one for IO setup, one for write to pin, one for read from pin. once I succeed I'll post that up as well. (I'll probably rummage through BP source for some hints).

P.S. It is confirmed to work with a 8Mhz crustal that doesn't use the right load capacitance, and has one of the crystals tracks broken on the board, that had to be rerouted with a wire. I'll post the pics later (thanks Arhi :)) So basicly becouse it works under those conditions I assume it will work in any other :D
best regards FIlip.

Re: PIC32 PTH breakout development

Reply #8
Moderate/Split these post if desired..

It seems we have some misunderstanding. However I can learn this now, if someone wants to teach (There is no back of the book to check answers against)
Here is the clock settings from the HID demo linked
Code: [Select]
	// Configuration Bit settings
// SYSCLK = 40 MHz (8MHz Crystal / FPLLIDIV * FPLLMUL / FPLLODIV)
// PBCLK = 40 MHz (SYSCLK / FPBDIV)
// Primary Osc w/PLL (XT+,HS+,EC+PLL)
#pragma config FPLLMUL = MUL_20, FPLLIDIV = DIV_2, FPLLODIV = DIV_2
#pragma config POSCMOD = HS, FNOSC = PRIPLL, FPBDIV = DIV_1

So to get the same 4*20/2 = 40MHz
#pragma config FPLLMUL = MUL_20, FPLLIDIV = DIV_5, FPLLODIV = DIV_2
I have confidence in this, but not 100%.

[quote author="Markus Gritsch"]@AndThen: You cannot brick the PIC32MX by using wrong config bits. It also accepts the connected PICkit 3 at every available PGEDx/PGECx pair. It just needs to be set correctly it you want to be able to debug the code. The clock/PLL config bits are also only necessary to be correct for *running* your code. Programming supplies its own clock via the PGECx pin.  So in any case, you can reprogram the MCU as often as you like without the possibility of bricking it, so keep trying.[/quote]

My programming device is not in fact pickit 2 or 3.  It is a parallax basicstamp2 homework board.
The programming connection used with the pic32 is the four wire ejtag.( so not only can I break it with config bits I'm pretty sure i can turn it off in software too.)
I have two programs for the stamp currently.
- one responds to the pickit2 command set. This is used with pic32prog.
- one responds to the bus pirate command set. This is used with the pirate pic programmer software.

I have added the stamp as an adapter to both, it is required since it is rs232 serial not USB.

pic32prog:
- read write and verify, test on mx110. It seems spot on. but my demo is crap (no surprise to me).

pirate:
- Tests have been completed on the pic18f2550 with IR toy and pickit2 firmware.

Before I had said "I had disabled the jtag pins in the config", this was bad recollection. I thought at one point I had.

What is written to this (unresponsive!) mx110 chip is,
Code: [Select]
(FPLLMUL)	PLL Input: 20x multiplier
(FPLLIDIV) PLL Input: 2x divider
(FPLLODIV) Default PLL:  output divided by 1
This is 8MHz input and 80MHz??

Here is the full parse output
Code: [Select]
(FPLLODIV)	Default PLL:  output divided by 1
(UPLLEN) USB PLL: enabled
(UPLLIDIV) USB PLL Input: 2x divider
(FPLLMUL) PLL Input: 20x multiplier
(FPLLIDIV) PLL Input: 2x divider
(FWDTWINSZ) Watchdog timer: window size is 25%
(FWDTEN) Watchdog timer: not enabled; it can be enabled in software
(WINDIS) Watchdog timer: non window mode
(WDTPS) Watchdog timer: postscale  1:1024
(FCKSM) Clock switching is disabled, Fail-Safe Clock Monitor is disabled
(FPBDIV) PBCLK is SYSCLK divided by 8
(OSCIOFNC) Clock out: disabled
(POSCMOD) Primary OSC: XT Oscillator mode selected
(IESO) Two speed start: disabled
(FSOSCEN) Secondary OSC: disabled
(FNOSC) Oscillator select: Primary Oscillator (POSC) with PLL module (XT+PLL, HS+PLL, EC+PLL)
Code Protect: Disabled
Boot Write Protect: Disabled
Pgm Write Protect:  Disabled
ICESEL: PAIR 1
JTAG enabled
DEBUG enabled
This is either
  A) Serge's defaults from pic32prog, B) Modified versions of A,  C) Modified microchip examples.
Along with attempting to run at 80MHz, it wants 8MHz in not the 20 I am providing, the mx110 might be unahppy with USB since it has none.
"bit 4-3 ICESEL<1:0>: In-Circuit Emulator/Debugger Communication Channel Select bits" was apparently much too long of text. It seems clear it does not control the programming lines, once i went back and looked at the datasheet, or there should have been an ALL PORTS choice.

But it no longer responds to the stamp. I'll call it unhappy since it didn't visually smoke, and it needs further review still.

Re: PIC32 PTH breakout development

Reply #9
1. Don't provide misleading information like "and need to hook up the pickit to the correct serial line", if you don't use a PICkit.

2. Read the datasheet and the reference manual.  There is no way around it if you want to understand what is going on, and avoid strange behaviour.  You could start with these:
* PIC32 Family Reference Manual, Sect. 06 Oscillators (http://ww1.microchip.com/downloads/en/D ... 61112G.pdf)
* PIC32 Family Reference Manual, Sect. 33 Programming and Diagnostics (http://ww1.microchip.com/downloads/en/D ... 61129F.pdf)

3. Keep in mind that the PLL wants to be fed with a frequency in the range of 4 MHz to 5 MHz. (From the Reference Manual: "When using the PLL modes the input divider must be chosen such that resulting frequency applied to the PLL is in the range of 4 MHz to 5 MHz.")

4. The PIC32MX1 and PIC32MX2 series is only specified for 40 MHz max. frequency, not 80 MHz like the 3, 4, 5, 6, 7 series.  Although most of them seem to work fine at 80 MHz, I have at least one PIC32MX1 which stops working at >72 MHz.

Re: PIC32 PTH breakout development

Reply #10
darn i want to play with few PIC32, all samples are on hold for more than a month :o(
you all lucky people you have some  :o)
we all need 32bits power ! :o)

Re: PIC32 PTH breakout development

Reply #11
I have it working now too with a 4MHz crystal and with INTERRUPTS. The additional bug fixing requirement to get interrupts working is to change the vector in usb_device.c as it is different for the MX1 and MX2 families. (If microchip had of used the vector defined in there own headers this would have never been a problem. )

  #elif defined(__PIC32MX__)
    void __attribute__((interrupt(),vector(_USB_1_VECTOR))) _USB1Interrupt( void )
  #endif

Re: PIC32 PTH breakout development

Reply #12
arakis can you supply your source code . thanks...

Re: PIC32 PTH breakout development

Reply #13
[quote author="okanercan"]arakis can you supply your source code . thanks...[/quote]
hehe, sure thing, as soon as I find it...expect it in a couple of hours...

EDIT: sorry looked for it, but it seems to have been left behind on my rescent reinstall of windows... sorry..
best regards FIlip.

Re: PIC32 PTH breakout development

Reply #14
really, I get my hopes up :( . anyway thank you for your helpful posts...