1. Home
  2. Embedded Programming
  3. dsPIC33F programming

dsPIC33F programming

Hi all,

I've been busy building a board with a dsPIC33F on it, foolishly assuming that it would be easy to program (i've never used PICs before).

I'm glad to say that after much pain and grief I have managed to get code on to it, and written a programmer in the process.

For some reason I opted to hook it up to my parallel port rather than buy a proper programmer, although I was unable to find any open source programmers for the dsPIC33F, only the 30F, and they wouldn't work. After a huge amount of hacking about in python, finding the plentiful errors in Microchip's datasheets, reading the Amadeus

formatting link
code (many thanks to Bernhard!), I've bodged up a working programmer, which I've published here:
formatting link

Random discoveries if anybody is interested:

- You have to pull /MCLR high to make things go (touching the pin is enough!). I'm not sure why it isn't mentioned in any of the datasheets.

- The chips come with the JTAGEN fuse in the (nearly undocumented) FICD config word programmed, which causes JTAG to steal the I/O pins, and stops you flashing LEDs with them.

- For some reason, the chip *really* wants code to start at 0x200, with a jump to it from 0x0. The same code in 0x0 doesn't seem to work (causes it to reset itself!).

I hope this is of use to someone!

Jonny Barker

Reply to
Jonny Barker
Loading thread data ...

For very good reason.

Page 2 of microchip 70189B.pdf:

"The interrupt Vector Table (IVT) resides in program memory starting at 0x000004. The IVT contains 126 vectors ..."

Reply to
linnix

A fair point, although if no interrupts are used, won't they just act like program memory? The AVRs I've played with with allow you to ignore the IVT completely if you don't enable any interrupts. The PC just carries on incrementing regardless.

Jonny

Reply to
Jonny Barker

Hi Jonny,

There are recommendations for defensive programming that say you should set up every interrupt vector with a jump to a piece of code. Then in the event of an interrupt ocurring, maybe due to a hardware fault, the code will go to a safe place and you could record that this has happened for later diagnostic purposes. In the past I've directed all unused interrupts to a common ISR and stored a fault code, so you don't need to write 120+ ISR's!

Technically though I think you are right the PC should just carry on but it's potentially unsafe and maybe the PIC doesn't allow this. It sounds like the linker is already set up with the first real code at 0x200, you could probably change this in the linker control file but best not to.

Dave.

Reply to
dathome

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.