Skip to main content
Topic: Tester(s) needed 32bit deviceIDs (pic32 prelim) (Read 11759 times) previous topic - next topic

Tester(s) needed 32bit deviceIDs (pic32 prelim)

Hello, boredom sat in..

Adding support for pic32 requires firstly increasing the device id's to handle them.

Attached are two binaries (ubuntu 10.04).

id32mx, should identify a "PIC32MX120F032B" (easy enough to change just ask) and exit
and
picprog, should function as it did for prior supported chips.

Re: Tester(s) needed 32bit deviceIDs (pic32 prelim)

Reply #1
Would you like SVN access to commit your enhancements?
Got a question? Please ask in the forum for the fastest answers.

Re: Tester(s) needed 32bit deviceIDs (pic32 prelim)

Reply #2
I would suggest peer review before pushing it into SVN.

Re: Tester(s) needed 32bit deviceIDs (pic32 read/verify?)

Reply #3
Either no one has tried it or the 32bit ID's are working, So an update!

Assuming the write functions are correct,and then assuming the read function is correct, and assuming I didn't miss anything else in the identification. I assume this one might Identify, Read, and  Verify.

Updated:
 read, and write updated
 device id and mask.

New binary, Old(picprog) might create bricks of pic32 if asked =( sorry
 picprog32, clean version with just id size changes
 picprogRO, write and erase disabled from main()


New: added patch files!

EDIT: added hex file

Re: Tester(s) needed 32bit deviceIDs (pic32 prelim)

Reply #4
Thanks for the sources. And thanks for cleaning up some of the mess ;) (trailing spaces, etc..)

I don't think that the changes are ready to be pushed into the svn, unless we want to break something. There is a lot of stuff that is debug only.
Many IFDEFs that are NOT necessary for production version, like disabling write/erase. If the source is not stable and breaks chips it is not to be available to public!! Sooner or later someone will dig it up (Its a revision control system after all), and screw up things.

Also your code is based on pic24, and you still have the pic24 code inside pic32 file. Why keep it ? (even commented/if 0-ed)

Last thing would be the
multi
line
function
prototype. (PIC32_Write) :-)

Anyways keep up the good work. I have no PIC32 to test your code with, I will leave the testing to someone else.

Re: Tester(s) needed 32bit deviceIDs (pic32 prelim)

Reply #5
That first #if 0, in the PIC#@_Write needs to be a if 1 thats the ram to flash bit it's important!

Re: Tester(s) needed 32bit deviceIDs (pic32 prelim)

Reply #6
So I found a MANID (jdec manufacturers id) in section 32 (1), which accounts for the discrepancy of the id pickit uses and what I am using. So the 32 bit id isn't strictly needed, but (in flippant disregard for my usual hatred of bloat) doesn't hurt (much).

pickit2, they have that handy device file editor.  easier to have the BP act as a pickit2 and use that uploader, or to implement a reader and back end for the config?

1:http://ww1.microchip.com/downloads/en/DeviceDoc/DS-61124E.pdf
2:http://code.google.com/p/pic32prog/source/browse/trunk/adapter-pickit2.c maybe a better source somewhere

My bs2 simulation only completes under strace or with a gdb induced delay, I'd like to blame windows but it's likely my typo somewhere, maybe lots of things hah..

Re: big A#@ device file

Reply #7
Randomly picking this thread to dump patches into, and continue discussion, over the other thread..

In an effort to feel productive I want to submit the full device list, today. Please pick a size format or recommend another.
Code: [Select]
                ,[PIC_MEM_FLASH] = {
                        .base = 0x1D000000
                        ,.size = 1 + ( 0x1D03FFFF - 0x1D000000 )        //262144

                }
Code: [Select]
                ,[PIC_MEM_FLASH] = {
                        .base = 0x1D000000
                        ,.size = 262144 //0x1d03ffff-0x1d000000
                }

There are some changes.
 Related to the device id.  The ones I use are 32bit and consistent with MPLAB and/or other microchip tools. Related to the device names.  The ones I use include the prefix pic18 dspic30.
 Related to the prelim patch.  The mask applied in at least one family is backwards,  proving no-one tested it.
 (simple test is i think,picprog -p PROG -u PORT -s SPEED -c CHIP -I, it might expect the -t argument also but I don't think so)

There are probably 10-20 questions I really should have wrote down that belong here.. o/

 Found one,  can someone explain the PIC416Read. Why the command is 0x9, I thought there were only two commands 0 and 2, for the pic18's. I'll have to look for that 4bit table again. Also they change places length and cmd?  I get stuck here, what the two software do is murky for me.
To write eeprom data, they have this bit on page 21, http://ww1.microchip.com/downloads/en/D ... 39622L.pdf
Code: [Select]
Step 6: Poll WR bit, repeat until the bit is clear.
...
0010 <MSB><LSB> Shift out data
The pic32 examples use the pic cpu, these pic18 want the host/programmer to poll and check, thats fine. but how I'm expecting  iface->PIC416Read(0x2,buffer,2) is wrong. whats the magic behind the 9 =(

Probably some others this will do for now.

Re: Tester(s) needed 32bit deviceIDs (pic32 prelim)

Reply #8
How about you leave the comas where they were ?:-)

If you prefer sizes as decimal that's fine. But could you make it like multiplication of smaller numbers?
instead of 524xxx = 512*1024, 262144 = 256*1024...

like:
Code: [Select]
   [PIC_MEM_FLASH] = {
                        .base = 0x1D000000,
                        .size = 256*1024 //0x1d03ffff-0x1d000000,
                },

Protocol was designed by Ian and others. My knowledge is not that far. (And my head hurts so much, that i could bearly understand what you are asking :-) ).

But please make the patch as close to the current formating as possible. (tabs, no spaces, no trailing space on line, etc etc. )

Re: Tester(s) needed 32bit deviceIDs (pic32 prelim)

Reply #9
Oh the comma drama!! You demonstrated why they teach to put the commas at the front rather well.  I think the ",." looks ugly also, but it has advantages.
This has the "wrong" family, ignore it.
Code: [Select]
{
        .family = FAMILY_18xxxx
        .name  = "PIC18F2550",
        .ID    = 0x00001240,
        .memmap = {
                [PIC_MEM_FUSE] = {
                        .base = 0x00300000,
                        .size = 14      //0x30000d-0x300000
                }
                ,[PIC_MEM_FLASH] = {
                        .base = 0x00000000,
                        .size = 32768  //0x7fff-0x0
                }
                ,[PIC_MEM_EEPROM] = {
                        .base = 0x00000000,
                        .size = 256    //0xff-0x0
                }
        }
}, // END device: PIC18F2550
I think it might of been an aesthetic choice,  256*1024 is just over one tab-width. Oh and it doesn't agree with my simple math
Code: [Select]
                        .size = 0.013671875*1024        //0x30000d-0x300000
fine fix that and we get another one.
Code: [Select]
.size = 11.984375*1024  //0x1fc02fef-0x1fc00000
I've always kind of thought these should be .base .end and maybe a .step *mumble, if it's not one thing it is another*

You want small decimals, it/I want bytes, how about we both suffer and I'll make it just the hex as referenced in the comments
Code: [Select]
.size = 1+(0x1fc02fef-0x1fc00000);
reduces to
Code: [Select]
                ,[PIC_MEM_BOOT] = {
                        .base = 0x1FC00000,
                        .size = 0x00002FF0
                }
I moved all the other commas but this one needs to stay or I'll have to add the PIC_MEM_LAST to get proper termination.

 Unsure if the compilers add terminating commas, or if it's squelching a warning. Anyone know offhand, guess I might look at the intermediate build files.
Code: [Select]
                       },
                        /* TODO
                        [PIC_MEM_EEPROM] = {
                                .base =
                        }*/

I might be beginning to ramble so i better stop. long time ago =)

Re: Tester(s) needed 32bit deviceIDs (pic32 prelim)

Reply #10
The 9 thing is probably a Bus Pirate command instead of a PIC command. If you check the Bus Pirate source in the raw2wire.c (I think) towards the end are the PIC programming commands. They are somewhat optimized to make PIC programming faster by doing common repetitive stuff on the uC instead of controlling it all over serial.
Got a question? Please ask in the forum for the fastest answers.

Re: Tester(s) needed 32bit deviceIDs (pic32 prelim)

Reply #11
I just hope you are kiddding with the 0.xxxxx numbers. You can always write the number as 0x2ff0 = 12*1024-16. This way you see
that it is 16 bytes from 12k boundary. Or just leave it hex.  (Your opinion seems to change at random. (-: ).

Re: Tester(s) needed 32bit deviceIDs (pic32 prelim)

Reply #12
Thank you both, again.

There is a raw wire command 0x09, it however selects (I think) three wire mode.  In the current svn I found the pic commands, in the pic file of all places!  BP uses the four highest bits, 9 is only four bits 1001.

 I found the full four bit pic command list it's page 12 of this programming specification.
http://ww1.microchip.com/downloads/en/D ... 39622L.pdf
Also on page 12 of this one, but this is the one that led me to think there were only two
http://ww1.microchip.com/downloads/en/D ... 39768d.pdf

Quote
I just hope you are kiddding with the 0.xxxxx numbers. You can always write the number as 0x2ff0 = 12*1024-16. This way you see
that it is 16 bytes from 12k boundary. Or just leave it hex. (Your opinion seems to change at random. (-: ).
I assure you, I would not put float it was only for demonstration.  The problem only shows up, I think for the pic32 devices, where the configuration is included in another section. I completely overlooked this solution.

Here is the 18F2550, it seems fine
Code: [Select]
        {
                .family = FAMILY_18Fx5xx
                .name  = "18F2550",
                .ID    = 0x00000092,
                .memmap = {
                        [PIC_MEM_FUSE] = {
                                .base = 0x00300000,
                                .size = 14
                        },
                        [PIC_MEM_FLASH] = {
                                .base = 0x00000000,
                                .size = (32*1024)
                        },
                        [PIC_MEM_EEPROM] = {
                                .base = 0x00000000,
                                .size = 256
                        },
                }
        },

And here another family sample.
Code: [Select]
        {
                .family = FAMILY_24FJxxGA0xx
                .name  = "24FJ64GA002",
                .ID    = 0x00000447,
                .memmap = {
                        [PIC_MEM_FUSE] = {
                                .base = 0x0000ABFC,
                                .size = 4
                        },
                        [PIC_MEM_FLASH] = {
                                .base = 0x00000000,
                                .size = (43*1024)-4
                        },
                }
        },
For the PIC 24 I corrected the config space from eeprom to fuse, they were in the flash space fortunately due to the size error. The config size also appears to be maybe words for the 24, it is now consistantly bytes. There are some notable relations.  Some devices have unimplemented sections in the config, some include device ID, and some may even store a double set of configs.

And a pic32, these add unique boot areas, and ram space to the memmap.
Code: [Select]
        {
                .family = FAMILY_32xxxx
                .name  = "32MX360F256L",
                .ID    = 0x00934053,
                .memmap = {
                        [PIC_MEM_FUSE] = {
                                .base = 0x1FC02FF0,
                                .size = 16
                        },
                        [PIC_MEM_FLASH] = {
                                .base = 0x1D000000,
                                .size = (256*1024)
                        },
                        [PIC_MEM_BOOT] = {
                                .base = 0x1FC00000,
                                .size = (12*1024)-16
                        },
                        [PIC_MEM_RAM] = {
                                .base = 0x00000000,
                                .size = (32*1024)
                        },
                }
        },

The family enum had issues (I couldn't ignore), The Family names are easily confused even more so if they do not match the datasheets.
Code: [Select]
enum {
        //"18F24J50",
        //      http://ww1.microchip.com/downloads/en/DeviceDoc/39687d.pdf
        FAMILY_18F2xJxx = 0,
                //Aliases
                FAMILY_18F4xJxx = 0,
        //"24FJ64GA002",
        //      http://ww1.microchip.com/downloads/en/DeviceDoc/39768d.pdf
        FAMILY_24FJxxGA0xx = 1,
                //Aliases
                FAMILY_24FJxxGA0 = 1,
        //"24FJ256GB106",
        //      http://ww1.microchip.com/downloads/en/DeviceDoc/39907b.pdf
        FAMILY_24FJxxGx1xx = 2,
                //Aliases
                FAMILY_24FJxxGA1 = 2,
                FAMILY_24FJxxGB1 = 2,
        //"18F2550",
        //      http://ww1.microchip.com/downloads/en/DeviceDoc/39622L.pdf
        FAMILY_18Fx5xx,
        FAMILY_LAST
};
This format is "dp device used", datasheet url, "prefered" Name, any alias. It is missing the "dsPIC33F/PIC24H" and  "PIC18F97J60". They require I think minor additions, device data and small differences in entry sequence like the pic18 differences.  The pic32 is removed, untill I find the BP documents or source (I have not properly looked for it admittedly).


And finally attached is picdevices.h, Take note it lacks the structure header and footer. it will need either pasted into, #include in the body of the struct, or minor edits w/ additional build rules. The device ID are unchanged excepting increases to full 32bit, eg they may not match mplab

EDIT: I hate comma, and it hates me too