Report Issue to Microchip about XC32 compiler header files

[BurnedResistor]

Dear All,

I am fairly certain that I have found an issue with the XC32 header files for the PIC32MX120F064H:

According to the datasheet, the RF6 GPIO is only available as such on chips without the USB model, which this chip is.
However, the header file does not contain this pin in neither the TRISF, LATF or PORTF structs:

Code: [Select]

typedef union {
  struct {
    unsigned TRISF0:1;
    unsigned TRISF1:1;
    unsigned TRISF2:1;
    unsigned TRISF3:1;
    unsigned TRISF4:1;
    unsigned TRISF5:1;
    unsigned :2;
    unsigned TRISF8:1;
    unsigned :3;
    unsigned TRISF12:1;
    unsigned TRISF13:1;
  };
  struct {
    unsigned w:32;
  };
} __TRISFbits_t;

I was not able to identify an easy way of reporting the issue to microchip, and even though half of me feels like there is no point in going through the hassel of trying to get this fixed if they will not make it easy for me, I still though it would be worth posting here, just to ask if someone has past experiences with reporting such issues.

Where would I go about reporting this?

Thanks for your help!

[Howardlong]

Dear All,

I am fairly certain that I have found an issue with the XC32 header files for the PIC32MX120F064H:

According to the datasheet, the RF6 GPIO is only available as such on chips without the USB model, which this chip is.
However, the header file does not contain this pin in neither the TRISF, LATF or PORTF structs:

Code: [Select]

typedef union {
  struct {
    unsigned TRISF0:1;
    unsigned TRISF1:1;
    unsigned TRISF2:1;
    unsigned TRISF3:1;
    unsigned TRISF4:1;
    unsigned TRISF5:1;
    unsigned :2;
    unsigned TRISF8:1;
    unsigned :3;
    unsigned TRISF12:1;
    unsigned TRISF13:1;
  };
  struct {
    unsigned w:32;
  };
} __TRISFbits_t;

I was not able to identify an easy way of reporting the issue to microchip, and even though half of me feels like there is no point in going through the hassel of trying to get this fixed if they will not make it easy for me, I still though it would be worth posting here, just to ask if someone has past experiences with reporting such issues.

Where would I go about reporting this?

Thanks for your help!

Did you raise a ticket?

I accept that Microchip are useless at responding, and close tickets without resolution, but pretty much unless you are lucky enough to have an FAE interested enough, you're pissing in the wind quite frankly. Raising a ticket is the only correct procedure, although having said that documenting it in a post on their forum as a consideration for others in the community is appreciated.

The smart arses on there might occasionally say "it's a documented problem" but then not tell you where it's documented, or where to get details of other similar facets from this imaginary feature repository. Ignore them! The fact you've documented it will help others.

[BurnedResistor]

Dear All,

I am fairly certain that I have found an issue with the XC32 header files for the PIC32MX120F064H:

According to the datasheet, the RF6 GPIO is only available as such on chips without the USB model, which this chip is.
However, the header file does not contain this pin in neither the TRISF, LATF or PORTF structs:

Code: [Select]

typedef union {
  struct {
    unsigned TRISF0:1;
    unsigned TRISF1:1;
    unsigned TRISF2:1;
    unsigned TRISF3:1;
    unsigned TRISF4:1;
    unsigned TRISF5:1;
    unsigned :2;
    unsigned TRISF8:1;
    unsigned :3;
    unsigned TRISF12:1;
    unsigned TRISF13:1;
  };
  struct {
    unsigned w:32;
  };
} __TRISFbits_t;

I was not able to identify an easy way of reporting the issue to microchip, and even though half of me feels like there is no point in going through the hassel of trying to get this fixed if they will not make it easy for me, I still though it would be worth posting here, just to ask if someone has past experiences with reporting such issues.

Where would I go about reporting this?

Thanks for your help!

Did you raise a ticket?

I accept that Microchip are useless at responding, and close tickets without resolution, but pretty much unless you are lucky enough to have an FAE interested enough, you're pissing in the wind quite frankly. Raising a ticket is the only correct procedure, although having said that documenting it in a post on their forum as a consideration for others in the community is appreciated.

The smart arses on there might occasionally say "it's a documented problem" but then not tell you where it's documented, or where to get details of other similar facets from this imaginary feature repository. Ignore them! The fact you've documented it will help others.

That's kinda the feeling I got. Ah well.. screw it.

Possible workaround is to just read the whole port and bitmask + shift, or write to the set register. Again  you will have to write to the whole set register..

Can test this though. No hardware around atm. ÍF anyone has something to test on, or knows about workarounds... let us know:)

Sent from my SM-N7500Q using Tapatalk

[mikeselectricstuff]

Possible workaround is to just read the whole port and bitmask + shift, or write to the set register. Again  you will have to write to the whole set register..

or just fix the header file...

[Howardlong]

Possible workaround is to just read the whole port and bitmask + shift, or write to the set register. Again  you will have to write to the whole set register..

or just fix the header file...

...and have to maintain it, if, for example, you want to build your code on another machine :-(

Personally in situations like this if possible I'd prefer do a workaround in my own source code with appropriate comments without messing with vendor supplied code, but sometimes I accept that pragmatically speaking needs must. Never say never, because I know I have been known to perform exactly such aberrations before. The trick is remembering you've done so, and that gets harder as you get older!

[Ian.M]

Microchip's datasheets are often buggy with significant copy/paste errors of information from similar devices that doesn't apply.  The device specific includes can be more accurate than the datasheet, so check out that pin by reading/writing the whole port under a hardware debugger before reporting it.

I would strongly recommend raising the issue on Microchip's XC32 forum, and give it a day or so to see what the community's opinion is first.  If you get confirmation, you can always point the support team at the forum thread, and it often gets escalated faster that way because they know that PEBKAC issues have already been eliminated. Also some of the various compiler team members hang out on the forums on their coffee breaks, and 'adopt' issues they have discussed with you as soon as your ticket goes in the queue.

To actually raise a support ticket (or whatever they are calling the process this month), you need to log in to microchip.com, goto http://www.microchip.com/support/hottopics.aspx, then click [My Support] then [Cases] then [New Case]

N.B. the main Microchip site (including support) shares logins with microchipdirect.com, but the Microchip community forums are a completely different login system with separate registration and user names.

[dannyf]

Possible workaround is to just read the whole port and bitmask + shift

You can also define your own struct and point it to the TRISx.

I prefer mask myself.

[nctnico]

Possible workaround is to just read the whole port and bitmask + shift, or write to the set register. Again  you will have to write to the whole set register..

or just fix the header file...

...and have to maintain it, if, for example, you want to build your code on another machine :-(

This is one of the reasons I make part specific include files part of the source code.