PIC32 LED blinker

Can you debug with the PICKIT3? I'd read the CONFIG reg's and see if the code protection bits are set. But it's typically not a problem if you program the chip. Second guess is the programming lines are not connected properly. Thrid, bad chip (happens once in a blue moon)

Cheers

[snip]

The OP mentioned the Vcap pin, but did not say whether he had a cap on it. The '150 needs a cap on the Vcap pin, or else it won't even program.

To the OP: see p.28 of the datasheet.

e code protection bits are set. But it's typically not a problem if you pro gram the chip. Second guess is the programming lines are not connected prop erly. Thrid, bad chip (happens once in a blue moon)

No, need to be able to program before debug.

. The '150 needs a cap on the Vcap pin, or else it won't even program.

Yes, i have 10uF cap on VCAP.

MPLAB X? Did you select the right COMM Channel for PGED1/2? Window->Pic Memory Views->Configuration Bits - ICESEL

Cheers

Do you get an error message when you try to program?

the code protection bits are set. But it's typically not a problem if you program the chip. Second guess is the programming lines are not connected p roperly. Thrid, bad chip (happens once in a blue moon)

it. The '150 needs a cap on the Vcap pin, or else it won't even program.

Memory Views->Configuration Bits - ICESEL

Yes, MPLAB on Linux. Using PGEx1 (pin 4 & 5). 8M /2 * 16 /2 = 32M, below 40M max. Also tried lower.

(For another thread) Error message is: Programmed device and target memory missmatch. Memory is always 0xFFs.

If they can get it working with solderless plug-in board, i should be able to get it working with soldered prototype board. I am thinking it's either the chip's hardware or MPLABX's software problem, since this is a relative ly newer chip.

/* Configuration Bits */ #pragma config PMDL1WAY = OFF // Peripheral Modle Disable Confi guration #pragma config IOL1WAY = OFF // Peripheral Pin Select Configur ation #pragma config FUSBIDIO = ON // USB USID selection #pragma config FPLLIDIV = DIV_2 // PLL Input Divider (PIC32 Start er Kit: use divide by 2 only) #pragma config FPLLMUL = MUL_16 // PLL Multiplier #pragma config FPLLODIV = DIV_2 // PLL Output Divider #pragma config FNOSC = PRIPLL // Oscillator Selection #pragma config FSOSCEN = OFF // Secondary Oscillator Enable #pragma config IESO = OFF // Internal/External Switch-over #pragma config POSCMOD = XT // Primary Oscillator #pragma config OSCIOFNC = OFF // CLKO Enable #pragma config FPBDIV = DIV_2 // Peripheral Clock divisor #pragma config FCKSM = CSDCMD // Clock Switching & Fail Safe Cl ock Monitor #pragma config WDTPS = PS1 // Watchdog Timer Postscale #pragma config FWDTEN = OFF // Watchdog Timer #pragma config JTAGEN = OFF // JTAG Enable #pragma config ICESEL = ICS_PGx1 // ICE/ICD Comm Channel Select #pragma config CP = OFF // Code Protect #pragma config BWP = OFF // Boot Flash Write Protect #pragma config PWP = OFF // Program Flash Write Protect #pragma config DEBUG = OFF // Debugger Disabled for Starter Kit

[snip]

Thst could be a problem in the mplabx chip definition.

I run MPLAB v8.92 on WinXP, and I use PicKit3 and the '150 on it regularly.

If nothing else works, try getting an old Winbox and load up v8.92. That might at least tell you if it's an issue with your mplabX.

If your circuit runs on breadboard, but not on a pcb, it's probably the pcb. Try programming a bare pic with only the filter caps and no other circuitry.

Some other things to check: Are you using the Pickit3 to power the whole circuit? In the past, I found pickits wouldn't program if the circuit drew too much power. If you are using external power, have you told the pickit to not supply power?

I have 8.76 on Win7, but it won't program 150s.

OK, will try 8.92. But i would like to move away from Windows eventually.

There is nothing else other than the PIC, crystal and caps.

PICKIT3 powering the chip and nothing else. It should be able to handle just one chip.

I have not used the PIC32, but it's a MIPS core, and should be able to run code fine from ram. For most 32-bit microcontrollers, you can set up your linker to put the code in ram rather than flash, and download and debug that way. This would let you test the chip and the board before figuring out the flash programming issue.

the code protection bits are set. But it's typically not a problem if you p rogram the chip. Second guess is the programming lines are not connected pr operly. Thrid, bad chip (happens once in a blue moon)

n code fine from ram. For most 32-bit microcontrollers, you can set up you r linker to put the code in ram rather than flash, and download and debug t hat way. This would let you test the chip and the board before figuring ou t the flash programming issue.

Yes, that's pretty much building my own PICKIT3. I am not ready to take on this project yet. Considering that i am building programmers for GAL, AVR and ...

Why are you bothering with the PIC32, if I may ask? As far as I can see, it's a losing battle. Microchip have lost out by picking MIPS instead of the same Cortex M3/M4 core that everyone else picked (and then competing on peripherals, prices, availability, dev kits, etc., like everyone else). MIPS lost out by picking Microchip which has lead to their rather excellent cpu cores being viewed as a device for hobby users with very poor performance (partly due to Microchip's idiotic policies on compiler optimisation, and partly due to Microchip's reputation for /all/ its cores being poor performers).

[snip]

Understandable. At this point we're trying to narrow down the list of suspects.

If the Win version works, that tells you the hardware's fine, and where the problem lies.

If the winbox/8.92/pickit3 will program other chips, but your '150 gives an error, then you have an issue with your pcb or your chip. Or your pickit3.

, it's a losing battle. Microchip have lost out by picking MIPS instead of the same Cortex M3/M4 core that everyone else picked (and then competing o n peripherals, prices, availability, dev kits, etc., like everyone else). MIPS lost out by picking Microchip which has lead to their rather excellent cpu cores being viewed as a device for hobby users with very poor performa nce (partly due to Microchip's idiotic policies on compiler optimisation, a nd partly due to Microchip's reputation for /all/ its cores being poor perf ormers).

That's not my experience with PIC32. Performance is very acceptable, even with non-optimized compiler. I don't see much difference between PIC32 and ARM. In certain way, the PIC32 I/O is better than some ARM.

I have worked with AVR, PIC32 and ARM. What have you worked with?

I didn't mean that the performance of the MIPS core in the PIC32 was bad

- merely that it was /perceived/ as bad. It is a solid core, because it was designed by good cpu designers rather than Microchip. (Microchip has plenty of strong points - but core design and toolchains are not amongst them.) The core is going to have similar performance to a Cortex M3 at the same clock speed (and MIPS' newer cores are faster).

A number of ARM devices, especially pre-Cortex, were quite poor at I/O - some were extraordinarily slow at simple GPIO bit-banging. But that is not the case with most modern Cortex M microcontrollers.

The full list is almost endless, but includes AVR (many models), msp430, PIC16, Cortex M3/M4, 68332, Coldfire, MPC5xx and MPC5xxx (PPC cores), a couple of MIPS devices, Nios, XMOS, COP8, and a couple of DSP's. These days it is mostly mps430 and Cortex M4 (Freescale Kinetis) that I work with.

The Cortex M3/M4 devices are taking over much of the market now - there are many advantages in being able to pick devices from different suppliers with the same basic core, and the price, size and power are so low that it is hard to justify 8-bit or 16-bit micros for most applications.

But I would have liked to see an alternative core vendor competing - it's not healthy for the market to be dominated too much. MIPS are the right people - they have cores that match or beat each of ARM's cores, and since the most critical development tool (gcc) is solid and mature on MIPS it is easy for developers to swap cores. But MIPS needs at least a couple of good microcontroller vendors to push the core into the microcontroller mainstream - and Microchip is not the right choice.

I agree with the compiler comment, at least partially. But as for the PIC3

2, I like it. I don't care what core it has. It performs well and, as is typical with Microchip, low pin count PDIP packages holding powerful micros are available which is great for the hobbyist. Where else can you get a 2 8 pin PDIP 32 bit micro with 64K SRAM?

I've used AVR and Freescale a little, and TI ARM extensively and as I see i t, you choose what works. I've used a 28 pin PIC32 QFN in a product we des igned. It's perfect because we needed some number crunching power, but few I/O. I personally hate the memory architecture of the low end PICs but th e compiler takes care of it. There's a PIC out there for nearly any applic ation, and that's why I primarily use them.

Shamefully admitting a wiring error. It works now. so i am ready to build the GAL programmer. First thing is to figure out how to provide:

3V 40mA for PIC32 5V 100mA for GAL22V10 12V 20mA for reading 15V to 18V for writing

I am thinking about boosting from 5V to 18V, then switch down to 12V. LDO for 5 V to 3V.

We expect perhaps 5 to 10 GAL patterns stored by the PIC, then just selectively program one of the pattern with toggle switches. We might even be able to enter equations with toggle switches, lots of switches.