Mx7 Button 3 and JTAG Conflict

[JimL]

Hello,

I'm using a ChipKit Mx7 Pro as a development platform, and have started out just trying to write some basic support routines for the user LEDs and buttons and talking to an LCD module as a warm-up before getting into my actual application code.  Once these are vetted I plan to add support for the I2C, SPI and UART ports, essentially putting together a minimal BSP which should be useful in my final application.

I've got the LED routines written and am blissfully talking to the LCD module.  I have BTNs 1 & 2 working but am having trouble reading button three.  The Mx7 user manual states that since Button 3 is shared with the JTAG controller which is enabled on reset, the JTAG controller has to be disabled before button 3 can be accessed as an input.  I assume from this that simply using the PLIB port bit configuration macros, i.e. setting PA-0 as an input, is not sufficient.  Since my code for BTN 1 & 2 work and for BTN 3 does not, this seems like a logical assumption.  The manual gives the following command to disable the JTAG controller:

     DDPCONbits.JTAGEN = 0;

When I use this command I get build errors.  I'm using:

     xc32 v1.42

     MBLABX v3.45

I've linked in the legacy PLIBs and configured the compiler to suppress the PLIB error/warning messages and have used the legacy PLIB to configure LED and button IO ports etc.

Looking on the web, I've found references to the following commands, all of which are claimed to disable the JTAG controller, though it was not always clear if the commands presented applied to the 795F512L device on the Mx7.

     DDPCON = DDPCON & 0xFFFFFFF7;

     #pragma  config  JTAGEN  =  OFF

     mJTAGPortEnable (DEBUG_JTAGPORT_OFF);

     mJTAGPortEnable (0);

I've tried all of these versions (one at a time) and all produce compile / build errors, with the errors pointing directly at these statements / preprocessor directives.  After trying the various commands, I now get warnings / errors that a number of include files cannot be found.  If I comment out the JTAG disable command currently in use, the project builds and downloads OK, so the "cannot find include files <filename>" messages must themselves be in error?  The files that supposedly cannot be found include <xc.h>, <plib.h> and a number of the compiler libraries,  <stdio.h>, <stdint.h>, <string.h>, etc.  If these files truly could not be found, the project would not compile and build would it?

Is there a way to "erase" currently displayed error / warning messages in MPBLAX?  If they could be erased, it would be interesting to see if  they come back after doing a clean & build.

I'm primarily a HW guy, so I may be doing something silly here, but after looking at this for longer than I would like to admit, I can't see anything amiss.

Any comments or suggestions of what I might try would be greatly appreciated. 

Thanks much for any help.

Jim L

[jpeyron]

Hi @JimL,

Here is a tutorial that deals with button 3 and states both line below are needed:

DDPCONbits.JTAGEN = 0;    // Disable JTAB programming

PORTSetPinsDigitalIn(IOPORT_A, BIT_0);

 

I would also suggest looking at our learn site here as well.

 

cheers,

 

Jon

 

[JimL]

16 hours ago, jpeyron said:

Hi @JimL,

Here is a tutorial that deals with button 3 and states both line below are needed:

DDPCONbits.JTAGEN = 0;    // Disable JTAB programming

PORTSetPinsDigitalIn(IOPORT_A, BIT_0);

 

I would also suggest looking at our learn site here as well.

 

cheers,

 

Jon

 

Jon,

Thank you for your reply.  Though not stated in my original post, I do have the second statement you indicate in my code as  I explicitly configure the three button inputs as digital inputs via the simple init function below.

 void   InitUserBTNIO (void)
   {
      // Configure BTN IO as digital inputs.
      PORTSetPinsDigitalIn (UserBtn1Port, UserBtn1Bit);                              // UserBtnxPort and UserBtnxBit references are defined in an associated h-file See below.
      PORTSetPinsDigitalIn (UserBtn2Port, UserBtn2Bit);                              // 
      PORTSetPinsDigitalIn (UserBtn3Port, UserBtn3Bit);
   };

 

   #define   UserBtn1              1                                   // Numeric User BTN1 reference  
   #define   UserBtn1Port       IOPORT_G                   // User BTN1 IO Port assignment
   #define   UserBtn1Bit         BIT_6                            // User BTN1 port bit assignment

   #define   UserBtn2              2                                   // Numeric User BTN2 reference
   #define   UserBtn2Port      IOPORT_G                   // User BTN2 IO Port assignment
   #define   UserBtn2Bit         BIT_7                           // User BTN2 port bit assignment

   #define   UserBtn3             3                                   // Numeric User BTN3 reference
   #define   UserBtn3Port      IOPORT_A                   // User BTN3 IO Port assignment
   #define   UserBtn3Bit        BIT_0                            // User BTN3 port bit assignment

That's my confusion.  What appears to work for buttons 1 and 2 does not work for button 3. 

The error message in MPLABX seems to point to its inability to recognize the 'JTAGEN' symbolic reference.

make[2]: Entering directory 'C:/Users/jlarrabee/Documents/uChip_WLT_12202016/PIC32Projects_12022016/Mx7ck_CLPwBTNs/Mx7ck_CLPwBTNs.X'
C:/Users/jlarrabee/Documents/uChip_WLT_12202016/PIC32Projects_12022016/Mx7ck_CLPwBTNs/Mx7cKCFG.c:65:11: error: unknown configuration setting: 'JTAGEN'
   #pragma config JTAGEN      = OFF

Is there some other configuration statement that potentially has to be coupled with the JTAGEN statement? 

Is there an "order" requirement that must be followed, i.e. an order of include files or order of the JTAGEN and IO Port Bit configuration statements?

This would at first appear to be a rather simple problem, but I've tried a number of things such as deleting and re-entering the various JTAGEN configuration statements, changing their location in the listing, etc.  I get the same/similar MPLABX errors each time.  Has Microchip done something in an attempt to try and force folks to use Harmony?

Thanks again for your help.

Jim L

[jpeyron]

Hi @JimL,

I missed your comment about the compiler not finding plib.h. If you have not added the plib.h here is where it is at. I believe that might be the issue.  Here is a getting started tutorial that might be helpful as well. It is for a different board but you will have similar needs for the Pro MX7.

cheers,

Jon

[JimL]

On ‎7‎/‎11‎/‎2017 at 5:26 PM, jpeyron said:

Hi @JimL,

I missed your comment about the compiler not finding plib.h. If you have not added the plib.h here is where it is at. I believe that might be the issue.  Here is a getting started tutorial that might be helpful as well. It is for a different board but you will have similar needs for the Pro MX7.

cheers,

Jon

Jon,

A little more information in the continuing saga.  I've looked at the button voltages on the board.  I probed at R1 for BTN 3 and the two vias at processor pins 10 and 11 for BTNs 1 & 2 respectively.  BTNs 1 & 2 show 0V when not pressed and 3.25V when pressed.  Pretty much what one would expect based on the board schematic.  BTN 3 on the processor side of R1 reads 1.84V when not pressed and 3.25V when pressed.  The same BTN 3 readings are obtained on the board side of R1 and at a trace via near the center of the board. 

 I measured all resistors and they measure as expected.  I have measured the same levels on two different Mx7 boards.  Based on the schematic, I'm a little pressed to explain the 1.84V BTN 3 level when it is not pressed.  It's as if the command to set Port A - B0 as an input really isn't getting executed? 

With regard to PLIB and other libraries, I believe everything is fine on that front.  I've actually got a fair amount of other code written besides the button processing to be able to use the Mx7 as a development platform for my project, and it all works fine, and I am starting to work on my actual target goal of implementing some generic profiled step motor motion routines.  I use the legacy PLIB functions freely throughout this code.  The version of MPLABX I am using (v3.45) tends to show LOTS of errors that references can not be found when you hover the cursor over source code lines in the files, yet the project builds and downloads just fine.  I tend to believe that MPLABX has some issues, probably related to Microchip trying to force Harmony on everybody.  You have to go into MPLABX and set a tool configuration macro just so the tool doesn't spit out a ton of PLIB warnings / errors.  I suspect this single macro doesn't totally compensate for whatever Microchip has done internally to try and convert over to Harmony.  It's to bad they couldn't have just let end users decide for themselves how they wanted to use their products and tools vs. deciding for everyone what is best for them.  Sorry, a little of my frustration with Microchip bleeding through here.

Based on the BTN 3 voltage measurements, I modified the simple test code I have been using by inserting a few hard delays.  The delays allow a visual check via debug messages sent to an LCD that the code is "closer" to working, but the 1.84V on BTN 3 is high enough that the button always looks as if it is pressed.  Soooo, in summary:

1. The code appears to work, i.e. all instructions appear to be executing, but BTN 3 always reads as if pressed, so it can't be used if the mystery 1.84V non-pressed level cannot be explained.

2. The MPLABX error that the JTAGEN symbolic reference was an "unknown configuration setting" not allowing the project to build and download must have been just another false indicator by tool, but one that actually caused the tool to choke.  I do not see at all how adding a few delays in the code could cause this message to go away and allow the build process to complete.

Sorry for the length of my tail of woe.  It's always amazed me how the simplest things can sometimes be the ones that seem to give the most grief.

Thanks much for you continued help. 

Jim L

 

 

[jpeyron]

Hi @JimL,

We are going to get this project working on the Pro MX7 tomorrow and see if we can duplicate this issue. 

cheers,

Jon 

Edit: Unfortunately we were not able to get to this today(7/14/17). We are hoping to have a working project either over the weekend or on Monday. Sorry about the delay.

[JimL]

On ‎7‎/‎13‎/‎2017 at 7:13 PM, jpeyron said:

Hi @JimL,

We are going to get this project working on the Pro MX7 tomorrow and see if we can duplicate this issue. 

cheers,

Jon 

Edit: Unfortunately we were not able to get to this today(7/14/17). We are hoping to have a working project either over the weekend or on Monday. Sorry about the delay.

Jon,

I really appreciate your efforts here.  Just so I could stay in sync, I downloaded the five files for Project 0, and set up a new project in MPLABX.  I wanted to be able to duplicate any findings you came up with on your end. 

After setting up the new project, I did a quick clean and build, and everything seemed OK, i.e. no errors.  If I'm not mistaken, this code simply manipulates a few variables and the primary goal is just allow one to try out various debugging tools such as breakpoints and parameter watches.  So I didn't expect to "see" anything when downloaded to the board,  and I didn't.  So I took a look at the config_bits.h and chipCit_Pro_MX7.h files.

chipCit_Pro_MX7.h contains #defines for the three button bits (I don't see the actual ports defined), similar for the four user LEDs.  Neither the buttons or LEDs appear to be used in the application (Project0.c)?

Looking at config_bits.h, I see the list of general PIC32 #pragma config statements I would expect.  I did not see a "#pragma config JTAGEN = OFF" statement.  I added one at the bottom of the file, i.e. just after the "#pragma config DEBUG = OFF" statement in the config_bits.h listing.

After adding this one line, the project would no longer clean and build.  I got the same error message I've been getting, i.e. the "JTAGEN" reference is not recognized and causes the build process to choke.

Have your experiences been similar or do things appear to work on your end?

My experience over the course of my career is that when I find myself in this type of situation, it's usually been my fault.  There's usually some small sequence or paired setting that I've failed to take account of, or there is some difference in development PC or some environment setting that needs to be altered.  The biggest problem is generally just finding out where it's documented to allow the situation to be corrected.   I suspect that will be the case here eventually.  I'm leaning toward believing there is some MPLABX macro setting that needs to be added / tweaked, but I've looked through a fair amount of Microchip documentation and haven't been able to anything related, I may not be searching the right areas or not using the correct search term.

Looking forward to hear what you've found out.

Thanks again for all your help.

Jim L

 

 

 

 

 

 

 

[JimL]

26 minutes ago, JimL said:

Jon,

I really appreciate your efforts here.  Just so I could stay in sync, I downloaded the five files for Project 0, and set up a new project in MPLABX.  I wanted to be able to duplicate any findings you came up with on your end. 

After setting up the new project, I did a quick clean and build, and everything seemed OK, i.e. no errors.  If I'm not mistaken, this code simply manipulates a few variables and the primary goal is just allow one to try out various debugging tools such as breakpoints and parameter watches.  So I didn't expect to "see" anything when downloaded to the board,  and I didn't.  So I took a look at the config_bits.h and chipCit_Pro_MX7.h files.

chipCit_Pro_MX7.h contains #defines for the three button bits (I don't see the actual ports defined), similar for the four user LEDs.  Neither the buttons or LEDs appear to be used in the application (Project0.c)?

Looking at config_bits.h, I see the list of general PIC32 #pragma config statements I would expect.  I did not see a "#pragma config JTAGEN = OFF" statement.  I added one at the bottom of the file, i.e. just after the "#pragma config DEBUG = OFF" statement in the config_bits.h listing.

After adding this one line, the project would no longer clean and build.  I got the same error message I've been getting, i.e. the "JTAGEN" reference is not recognized and causes the build process to choke.

Have your experiences been similar or do things appear to work on your end?

My experience over the course of my career is that when I find myself in this type of situation, it's usually been my fault.  There's usually some small sequence or paired setting that I've failed to take account of, or there is some difference in development PC or some environment setting that needs to be altered.  The biggest problem is generally just finding out where it's documented to allow the situation to be corrected.   I suspect that will be the case here eventually.  I'm leaning toward believing there is some MPLABX macro setting that needs to be added / tweaked, but I've looked through a fair amount of Microchip documentation and haven't been able to anything related, I may not be searching the right areas or not using the correct search term.

Looking forward to hear what you've found out.

Thanks again for all your help.

Jim L

Jon,

I looked a little closer at the Project0 example.  While it doesn't use a "#pragma config JTAGEN = OFF" preprocessor command, it does use  a "DDPCONbits.JTAGEN = 0;" statement in the chipKit_Pro_MX7.c file. 

I altered my code to include a "DDPCONbits.JTAGEN = 0;"  statement where I initialize the button IO, similar to the Project0 example and deleted (commented out) my "#pragma config JTAGEN = OFF" preprocessor command.  Low and behold, everything worked, i.e. my BTN3 code now executes OK! 

I had tried this and a few similar commands previously but with no luck.  I had tried them in a different spot, so maybe the sequencing was the issue.  In any case, I  obviously did something not quite right.  My past experience holds, when I have problems such as this, it's usually my fault.

I would prefer to use the pre-processor command to disable the JTAG port to allow having all the processor general configuration / setup in one place, but apparently this is simply not a valid preprocessor command, and this has to be done via an executable statement, similar to the final physical configuration of individual port bits.  I did a quick look in the PLIB user reference, and couldn't find this preprocessor command referenced, and I can't remember where I got it from, must have been a web posting.

Thanks much for pointing me to this example.  It was a great help.  Sorry for taking so much of your time with this issue.

Jim L

 

 

26 minutes ago, JimL said: