2
\$\begingroup\$

I'm trying to use the 4-bit wide PORTE on a PIC18F44K22 MCU. This port contains the RE3/MCLR pin which can be configured as a reset pin or as an input pin by setting/clearing the MCLRE bit on CONFIG3H.

No matter what value is set on the MCLRE bit, if the RE3/MCLR pin is held LOW, the MCU refuses to execute any instruction. Setting the RB3/MCLR pin up and the MCU works as expected (with one less onput pin).

This has been tested using a pickit 2 programmer and a multimeter, powering the MCU with the programmer itself. power pins on the MCU are decoupled using 1pF capacitors and an aditional 22uF capacitor on the board power input.

BOR is disabled and the program loaded is as simple as it can posibly be (set RB3 UP). Tested using both 5V and 3.2V

I have read of ESD ocasionally triggering resets but in this case is a low value keeping the device on reset.


Solution:
For MCLRE to have any effect, LVP bit must be disabled. In gpasm:

    CONFIG MCLRE  = INTMCLR
    CONFIG LVP    = OFF
\$\endgroup\$
  • \$\begingroup\$ Have you tried a separate power supply? That part has an issue that requires a bunch of current in startup under some conditions- the errata is weasely enough that it could apply. \$\endgroup\$ – Spehro Pefhany Nov 13 '14 at 9:28
  • \$\begingroup\$ 1pF decoupling caps? ... 100nF is more typical. Probably a typo I guess. \$\endgroup\$ – aja Nov 13 '14 at 12:32
  • \$\begingroup\$ Have you disabled "Single-Supply ICSP Programming" in your config bits (CONFIG4L.LVP)? \$\endgroup\$ – brhans Nov 13 '14 at 13:46
6
\$\begingroup\$

If you haven't disabled "Single-Supply ICSP Programming" in your config bits (CONFIG4L.LVP) then this would explain the behavior you're seeing.

Section 24.9 of the datasheet reads "While in Low-Voltage ICSP mode, MCLR is always enabled, regardless of the MCLRE bit, and the RE3 pin can no longer be used as a general purpose input."

\$\endgroup\$
  • \$\begingroup\$ Seems to be working now. Tanks! \$\endgroup\$ – NeonMan Nov 13 '14 at 15:27
1
\$\begingroup\$

This smells like your config bit settings aren't actually getting into the chip. Some possible reasons for this:

  1. You have MPLAB configured to have the config bits come from the GUI instead of your code.

  2. The programmer may not be set up to overwrite the config bits. Check the "programming range" (or something like that) in the setup.

  3. You need to re-import the code. I have noticed myself that after changing config bits in the source code, rebuilding, running MPLAB again, then programming the chip, the new config settings don't make it into the chip. I don't know if this is a bug or a feature, but the solution is to FILE > IMPORT the HEX or COFF file again, then re-program.

Use the config bits GUI in MPLAB to see how it thinks the config bits are set. Or even better, program the part then inspect the actual config bits in the chip with the debugger to see how they are actually set.

\$\endgroup\$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.