PIC24FJ64GA1/GB0 Support?

[jgrzesiak]

HI,

I'm trying to determine whether this utility can work with, or be modified to work with the PIC24FJ64GA1/GB0 family of chips. relevant programming reference

Looking at the source code for the unified PIC24FJ/dspic33e families, it doesn't look like that option is compatible with the programming specification for the GA1/GB0 families...but the PIC24FJXXGA0XX code does look close to compatible, if not completely (haven't had a chance to test it yet).

My question is: in the case that they aren't completely compatible, whether or not you had any suggestions/direction in augmenting the code to make it work?

Thanks!

[WallaceIT]

Hi, probably the PIC24FJXXGA0XX familiy is compatible or quite so, unfortunately I don't have such devices and cannot test on my own.

My advice is to check the programming timings and the overall sequence; if they are the same (or close enough - remember that microseconds and nanoseconds delays haven't much sense in a non-rt kernel), you can try with with this one.

If you have that possibility (I didn't when I wrote the first version), start from a know working firmware for your device.

Regards, Francesco

[smbrandonjr]

Hi,

In the device header where the device ID, name and MEMSIZE is defined, where is the MEMSIZE defined for the different chips? I am unable to find the same values in the datasheets. Specifically trying to add PIC24FJ256GB110. I have the ID but not sure what to use for the MEMSIZE. I am guessing at the moment and using the same value other 256 chips are using.

[jgrzesiak]

Take a look at page 40 of the family data sheet detailing the configuration word addresses.

If my recollection is correct, the main program uses MEMSIZE to jump to where those configuration words are in order to set them...so should end up looking like this:

        pic_device piclist[21] = {{0x1008, "PIC24FJ128GA106", 0x0157FA},
                      {0x1010, "PIC24FJ192GA106", 0x020BFA},
                      {0x1018, "PIC24FJ256GA106", 0x02ABFA},
                      {0x100A, "PIC24FJ128GA100", 0x0157FA},
                      {0x1012, "PIC24FJ192GA108", 0x020BFA},
                      {0x101A, "PIC24FJ256GA108", 0x02ABFA},
                      {0x100E, "PIC24FJ128GA110", 0x0157FA},
                      {0x1016, "PIC24FJ192GA110", 0x020BFA},
                      {0x101E, "PIC24FJ256GA110", 0x02ABFA},
                      {0x1001, "PIC24FJ64GB106", 0x00ABFA},
                      {0x1009, "PIC24FJ128GB106", 0x0157FA},
                      {0x1011, "PIC24FJ192GB106", 0x020BFA},
                      {0x1019, "PIC24FJ256GB106", 0x02ABFA},
                      {0x1003, "PIC24FJ64GB108", 0x00ABFA},
                      {0x100B, "PIC24FJ128GB108", 0x0157FA},
                      {0x1013, "PIC24FJ192GB108", 0x020BFA},
                      {0x101B, "PIC24FJ256GB108", 0x02ABFA},
                      {0x1007, "PIC24FJ64GB110", 0x00ABFA},
                      {0x100F, "PIC24FJ128GB110", 0x0157FA},
                      {0x1017, "PIC24FJ192GB110", 0x020BFA},
                      {0x101F, "PIC24FJ256GB110", 0x02ABFA}};
};

I'll confess, I've been bad and made some mods to this program to support a couple more pic families, but never submitting a pull request with the changes. I'll do that as soon as I get a chance because it should in theory work with the PIC24FJ256GB110

In case I get hit by a bus or something before I do that...hopefully the above should help.

[smbrandonjr]

@jgrzesiak thanks for that info.

I created a new .cpp and titled it pic24fjxxxgb0xx, which was a direct copy of pic24fjxxxga0xx.

Comparing the code and confirming with the data sheet, a majority of the specifics appeared to be the same. The main difference I saw was that it looks like the GB family has 3 config registers where the GS family only has 2. So modified a few areas in the .cpp related to that... mainly:

Line 597 const char *regname[] = {"CW3","CW2","CW1"};

Line 566 for (i = 0; i < 3; i++) {

Line 755 for (i = 0; i < 3; i++) {

Does this sound right to you or do you think I overlooked anything?

BTW, hope you don't get hit by a bus

[jgrzesiak]

That rings a distinctive bell of something I had to do. I don't think there was much else apart from throwing an entry in the big instantiation switch statement in picberry.cpp, and additionally adding it to the makefile.

I did end up submitting that pull request, if you wanted to see what I ended up doing and compare notes or use it entirely.

[smbrandonjr]

Awesome, thanks! I did compare and other than me being lazy and not using a proper name...code is the same.

So, when I first used picberry to flash my GB110 which is part of a Mikromedia for PIC24 dev board, I incorrectly flashed it as part of the pic24fjxxxga0xx family, so the config registers aspect of that code was wrong. So I assume I wiped the original bootloader that was on the chip.

I have a copy of the bootloader hex file. Is flashing the PIC with that any different than flashing a non-bootloader hex file? (If that question even makes sense...) Sorry I am pretty new to PICs and microcontrollers. Should picberry be able to flash this bootloader back, assuming the GB110 code is correct?

[jgrzesiak]

I'll be honest, I haven't really messed around with bootloaders on PICs, but from my limited understanding there should be no difference in how you program a bootloader, and normal hex file and you should be able to use it to flash the bootloader back.

The only difference being that at the end of the day, you can bypass the future need of a tool like picberry and use the bootloader itself to program the application code.

[smbrandonjr]

Well I really appreciate the discussion, it has been much help.

[WallaceIT]

Hi @jgrzesiak / @crazyboogs Sorry for not replying but I've been very busy latest months.

I merged your PR but didn't tested it, but if it's working for you...

I had the plan to rework the entire picberry structure, in order to unify similar families and so on, but didn't have much time. If you (or someone other) want to take the burden of maintaining and/or reworking, you'll be welcome.

Many thanks for your work!

[jgrzesiak]

Completely sympathize with the busyness...I've been much of the same the last couple months.

If I find some free time in the near future though, I might just take you up on that offer/burden of doing some reworking some of the picberry structure.

Let me know you had any existing plans/thoughts on what you were thinking about unifying/restructuring. Having done a lot of stuff with various 24F families, I can definitely see how it can be consolidated in places there, but my familiarity with the other families is mostly lacking.

[WallaceIT]

Hi @jgrzesiak for sure no plans, but I can share some thoughts:

• probably some families can be unified, since they share the same programming method and are different only on the timing side;
• when I first coded picberry I han no real-world experience in programming and now I can see many bad design choices. For example, C++ features (such as inheritance) shold be exploited more and in the right way;
• last but not least, some code cleanup is needed and coding style should be unified among families.

Those are only ideas, since at the moment (and in the near future, I fear) I have no much spare time and cannot properly test any modification.

Regards, Francesco

[smbrandonjr]

@jgrzesiak are you using a am335x with picberry by chance? I am hitting a snag when trying to use a gpio value that is 3 digits (gpio# 115)...I don't know c++ well enough to follow what is happening but think I have it narrowed down where the potential issue may lie.

[jgrzesiak]

I'm not using an am335x, but if i were to take a stab in the dark, I would guess that it might have something to do with OFFSET(g) calculating the wrong offset for GPIO bank 3.

If gpio 97 reproduces the same bug as the 3 digit gpio scenario, then that might just be it.