Skip to main content
Topic: PIC programming adapter problem (Read 22258 times) previous topic - next topic

PIC programming adapter problem

Hi,

I have a PIC programming adapter for a long time (yes, this is where all those were going :-)), and now I wanted to add support for 18F2553 (I assume it is very close, but may have a different ID than the 18F2550?)

Anyhow, I started a few hardware tests (set the power supply on, and the aux pin on), and verified I can see +12.5V on the MCLR pin in the adapter using a voltmeter.

I also ran HVPselftest.exe but I get the following message when I try:

 Press Esc to exit, any other key to start the self-test


Code: [Select]
 Starting test!
 Opening Bus Pirate on com7 at 115200bps...
 Configuring Bus Pirate HVP Adapter...
 Going into Binary Bitbang mode.. Entering binary mode...
ok
 configuring pins as output...
 sending 01000000... ERROR: BusPirate replied with 0x40 instead of 0x01
OK
 Sending Command to power on : 11000000.... ERROR: BusPirate replied with 0xffffffc0 instead of 0x01
OK
 Voltage Probe measurement...,sending 00010100
 ADC Reading:  0 Volts
 Voltage Measurement: !!!!FAIL!!!!
 powering off.....
 ERROR: BusPirate replied with 0xffffff80 instead of 0x01
 Press any key to continue...

Anyone has any idea why is the self test failing?
Is this test supposed to test anything above what I already tested with my DVM?
If the HW is indeed OK, should I bother trying to fix this problem?

I'm running on Windows 7/64 bit, and I'm able to communicate with my BPv3a over COM7 at 115200 baud.
Here is the version info of my BP:

Code: [Select]
1-WIRE>i
Bus Pirate v3a
Firmware v5.10 (r559)  Bootloader v4.3
DEVID:0x0447 REVID:0x3003 (24FJ64GA002 A3)
http://dangerousprototypes.com
CFG1:0xF9DF CFG2:0x3F7F
*----------*
Pinstates:
1.(BR)  2.(RD)  3.(OR)  4.(YW)  5.(GN)  6.(BL)  7.(PU)  8.(GR)  9.(WT)  0.(Blk)
GND    3.3V    5.0V    ADC    VPU    AUX    -      OWD    -      -
P      P      P      I      I      O      I      I      I      I
GND    3.31V  4.77V  4.28V  2.67V  H      H      H      L      H
Power supplies ON, Pull-up resistors ON, Open drain outputs (H=Hi-Z, L=GND)
MSB set: MOST sig bit first, Number of bits read/write: 8
a/A/@ controls AUX pin

*----------*
1-WIRE>

thanks,
Udi

Re: PIC programming adapter problem

Reply #1
Hi Udi,

Yes, it only checks those things. I'm not sure why it you get the errors. Does the programming app work at all?
Got a question? Please ask in the forum for the fastest answers.

Re: PIC programming adapter problem

Reply #2
Hi Ian,

I haven't gotten to that, as I haven't finished soldering the board . Judging the results so far (seeing that I got the required 13V), I'll go ahead assembling the board.

Udi

Re: PIC programming adapter problem

Reply #3
Ok, thank you. Please keep me updated :)
Got a question? Please ask in the forum for the fastest answers.

Re: PIC programming adapter problem

Reply #4
I had some error messages before. Cannot remember why and how, will do a check tonight to see if that is still the case (on windows7 - 64bit system). But I can use my adapter without any problem, but I use a Linux machine for that. There might be some problem in the test program related to communications, have to try it out.

Re: PIC programming adapter problem

Reply #5
A few updates:

I'm using a USB RGB color changer as my PIC proto board (thank Ian for the free PCB).
Using http://www.diylife.com/2008/01/25/make- ... ing-light/ as a reference, I found a few issues:
1. PGD and PGC are swapped on this PCB's ICSP connector.
2. The PCB is different than what's appearing the link above.

As a VCC source I ended up picking V+ from the BP's own ICSP, because I think V+ on the HVP adater's connector seems to be off by default.

This is what I got:

Code: [Select]
W:downloadspicprog.v0.2>picprog.exe -p buspirate -u com7 -s 115200 -c 18F2550
(Bus) Pirate PIC Programer v0.2

Initializing interface
115200
Entering binary mode
BP: Setup mode...
Setup peripherals...
(OK)
Found '18F2550' in programming database :) index = 0
Checking for 18F2550 attached to programmer...

Wrong device: 0X2A47 (ID: 0X152 REV: 0X7)

This was expected ofcourse. The 18F2553 is not supported yet, but it should be just an alias of the 18F2550, except for the ID code.

Visiting the SVN , I'm not sure which code to work on.
Under http://code.google.com/p/dangerous-prot ... atePICprog I see both 'software' and 'framework' which appear to be very similar. 'software' seems to be more recent though.
There is also OpenProg which is a different code base, but seems to support more chips.

Which one should I take? A RAEDME file on the SVN could help.

Re: PIC programming adapter problem

Reply #6
"software" directory is the correct one. Others are for programmers reference only.

Re: PIC programming adapter problem

Reply #7
Under "software" folder, there is a file named "pic.c", all definitions are there. You have to edit that one. I couldn't find my BP yesterday, turns out I left it at the hackerspace, I'll try the test program in a bit.

Re: PIC programming adapter problem

Reply #8
I verify that I see the exact same errors. I'll try to see what can be the problem. The thing is, if I turn power supplies on and then measure ADC, I get:
Code: [Select]
UART>W
Power supplies ON
UART>d
VOLTAGE PROBE: 4.26V
So now my guess is that there is a comm problem: Pins cannot be set as output and then power supplies cannot be turned on. Actually I see MODE and VREG LEDs flash but I still get the same error. If I dive a little deeper:

1) Configuring pins as output:
Sent: 01000000, Received: 0x40 (01000000), Expected: 0x01
Here we are trying to configure AUX, MOSI, CLK, MISO & CS as outputs. The return is current state of the pins and they should be low, so there is no error with the returned byte.

2) Sending command to power on:
Sent: 11000000, Received: 0xffffffc0, Expected: 0x01
Here we are trying to turn POWER pin on while keeping PULLUP, AUX, MOSI, CLK, MISO & CS low. The reply is in the same format, showing the state of the pins, so actually the received byte should be 11000000 (0xc0). There is definitely a problem here.

3) Voltage probe measurement:
Sent: 00010100, Received: ?, Expected: ?
With this command, an ADC measurement is taken and as an answer a 2 byte ADC reading is sent, with high 8 bits first.

4) Powering off:
Sent: ?, Received: 0xffffff80, Expected: 0x01
My guess is that now we are sending 0x0f, the reset command. The answer should be 0x01, with possible garbage data afterwards as UART is initialized again.

Ian, can you also try it out? If you also get the same problems, that means there is a problem with the self test program. I'll try to see if I can work out the code and spot any bugs there. As there is no QC sticker on the adapter, my guess is that this check is not being performed yet?

Edit: Made a mistake on powering off part, it is now corrected.

Re: PIC programming adapter problem

Reply #9
[quote author="tayken"]2) Sending command to power on:
Sent: 11000000, Received: 0xffffffc0, Expected: 0x01
Here we are trying to turn POWER pin on while keeping PULLUP, AUX, MOSI, CLK, MISO & CS low. The reply is in the same format, showing the state of the pins, so actually the received byte should be 11000000 (0xc0). There is definitely a problem here.
[/quote]

I guess this is a cast from signed char to signed long int .

Re: PIC programming adapter problem

Reply #10
Hi guys, sorry for my late reply here. I can't find my adapter right now, but I'll try to find it and do the test. To be honest, I wrote the self-test app in 5 minutes maybe a year+ ago, I don't really remember what is going on. Jamz may have recompiled the app with the updated serial library and it could be broken now, the bp frmware may be changed, maybe it is wrong version or? Just thinking about it makes me shudder ;) I know seeed used a self-test app to test the 20 developer units made.
Got a question? Please ask in the forum for the fastest answers.

Re: PIC programming adapter problem

Reply #11
Due to my limited free time, and the fact that I used this as an excuse to learn Eclipse, this took me some time, but I've managed to get my 18F2553 programmed.
On the way I also found a small bug: The datafile pointer was declared within main() and was not initialized, so when the -t option was not specified, it was not written, but still != NULL, which caused no warning to be displayed for not selecting a filetype, and when the program tried to read or write the data file, an illegal address is called (datafile->WriteFile() for example).

The 18F2553 patch is simple, and is based on cloning the 18F2550 entry in pic.c, but changing the ID from 0x92 to 0x152.

Do you want me to submit a patch (how?), or to apply this myself (I have commit access to the bus pirate SVN but not to this project).

thanks,
Udi

Re: PIC programming adapter problem

Reply #12
You can post your edit here and I can commit the changes to SVN.

Re: PIC programming adapter problem

Reply #13
Here is the patch. This fixes:
1. uninitialized pointer in main()
2. Adds 18F2553 support
3. Eases debugging when using the Eclipse IDE for debugging
4. Small typo fix in one of the messages

Code: [Select]
Index: pic.c
===================================================================
--- pic.c (revision 1529)
+++ pic.c (working copy)
@@ -43,6 +43,25 @@
  }
  },
  {
+ .name = "18F2553",
+ .ID = 0x152,
+ .family = FAMILY_18Fx5xx,
+ .memmap = {
+ [PIC_MEM_FLASH] = {
+ .base = 0x0000,
+ .size = 32*1024
+ },
+ [PIC_MEM_FUSE] = {
+ .base = 0x300000,
+ .size = 14
+ },
+/* TODO
+ [PIC_MEM_EEPROM] = {
+ .base =
+ }*/
+ }
+ },
+ {
  .name = "18F4550",
  .ID = 0x90,
  .family = FAMILY_18Fx5xx,
Index: main.c
===================================================================
--- main.c (revision 1529)
+++ main.c (working copy)
@@ -70,12 +70,18 @@
  uint32_t i;
  uint16_t PICidver, PICrev, PICid;
 
+#ifdef ECLIPSE_DEBUG
+// WIthout these, console output within Eclipse will be buffered
+ setvbuf(stdout, NULL, _IONBF, 0);
+ setvbuf(stderr, NULL, _IONBF, 0);
+#endif
+
  char *param_write_file = NULL;
  char *param_read_file = NULL;
  char *param_prog = NULL;
  char *param_port = NULL;
  char *param_speed = NULL;
- struct file_ops_t *datafile;
+ struct file_ops_t *datafile = NULL;
  char *param_chip = NULL;
  uint16_t cmd = 0;
 
@@ -88,7 +94,7 @@
  struct memory_t *memwrite;
 
 
- printf("(Bus) Pirate PIC Programer v0.2 nn");
+ printf("(Bus) Pirate PIC Programmer v0.2 nn");
 
 #ifdef DEBUG
  cmd |= CMD_ERASE;

Re: PIC programming adapter problem

Reply #14
Kinda scary, that every developer would add DEBUG option for his/hers favorite debugging program ...

Why not make it less specific, and name the define DEBUG instead of ECLIPSE_DEBUG ?