Prox / RFID
Ladder Logic
[interfacing] †
Tube Joints
Key Code From Photo
SolveSpace (3d CAD)
SketchFlat (2d CAD)
Resume / Consulting
Contact Me

LDmicro Forum - loading hex to pic makes port b blink...

(you are viewing a thread; or go back to list of threads)

loading hex to pic makes port b blink... (by Alex)
Hello, i have tested a blink led ladder with ldmicro, 5.1.0.c and 2.4, all fo them uses same output pin RA0, if i connect a led in any unused port B5, B4, B2 and B1 (B7,B6 and B3 are for ICSP) in ldmicro, that led blinks when uploading hex , also, if i enable pull up resistors in port B led in any port B keeps turned on after loading hex (it blinks when loading hex too) , that happens if i use ldmicro and 5.1.0.c but not with 2.4 :


with my arduino uno there is no problem yet with 3 ldmicro versions i have not seen led blinking when uploading hex, my arduino is a clone,

i wonder if i use some pics as plc what would happen if i load a hex and in any port be there is a relay that turns a motor on? what are the hardware techniques for this feature?
Tue Jan 22 2019, 20:56:42
(no subject) (by José GILLES)

Strange behaviour...

But I think that when you update a PLC you MUST shutdown all connected devices not to have unpredictable behaviour before startup ?

Wed Jan 23 2019, 03:58:49
Alex (by Calubert)
No dejes las entradas al aire, haz un división de tensión a las entradas, también puedes colocarlo un TOF para que el rele que tienes no se encienda hasta pasar el tiempo. tienes que tener en cuenta que segun que funciones necesites tienes que usar 2.4.
yo tengo PIC que no funcionan según con que versión
Wed Jan 23 2019, 05:55:22
loading hex to pic makes port b blink... (by DanielH)
Hi Alex!

Since Ihor Nehrutsa has forked LDmicro, he has changed the defaults for Port B inputs, enabling weak pull up resistors on those pins.

In old 2.4 version by Jonathan Westhues, Port B internal pull up resistors for inputs has been disabled as default.

I think (may be I'm wrong) that your problem is related to pull up resistors enabled at undeclared pins at Port B (inputs as default). Of course, this pb only arise using LDmicro 3.xx or higher.

Have you explicitly declared unused and unconnected pins at Port B as outputs, and drived those outputs LOW?

If not, they act as inputs with internal weak pull up resistors enabled, so any LED with its anode connected to one of those pins and its cathode connected to ground will be turned on (with a low bright due a very low current in input mode, typically 0.25 mA).

You can declare an unused Port B pin (or any I/O pin) as output, and set it as permanently LOW, connecting left rail directly to a negated (inverted) coil:


Don't forget to asign this output to the corresponding pin in I/O table!!!

I habitually use this "trick" with all the unused I/O pins, to avoid all kind of problems.

BTW: What is 0x81 register in your PIC, and why you set it to 0xFF at first cycle in your program?

Best regards,
Wed Jan 23 2019, 16:32:48
(no subject) (by Alex)
to DanielH

thanks for your reply, no i haven´t set them as output and LOW i am going to try that, about the 0x81 is for disabling pull up resistors:


here DFX said for disabling pull up resistor for pic

Wed Jan 23 2019, 16:41:08
(no subject) (by Greg Blackwell)

You said "i wonder if i use some pics as plc what would happen if i load a hex and in any port be there is a relay that turns a motor on?"

You must not assume that you can expect LDmicor to behave the same way as a commercial PLC.

LDmicro is a free and open-source complier. LDmicro is not a PLC.

You use LDmicro to write a program in Ladder Diagram code using the GUI and compile it to a hex file that you can write to a PIC microcontroller using a PIC programmer. This process is the same if you use MplabX to write a program in C and compile it to a hex file or you use write a program in BASIC and compile it to a hex file using GCB (Great Cow Basic).

You are correct that if your relays or motors are powered on when you program you PIC there could be some risk of the motor running when it should not.

As you are the person who wrote the program all the safety aspects about using this program is your responsibility, including ensuring that it i safe to write a new program to the PIC microcontroller. Two ways to do this would be to either turn the power off to everything but the microcontroller before you program the PIC or to unplug the microcontroller board from the rest of your system to program it.

The blinking RB5 LED could be a problem and if bug fixes continue for LDmicro or LDmico32 this would be a good thing to report to be investigated.
Wed Jan 23 2019, 23:47:47
loading hex to pic makes port b blink... (by DanielH)

I think that the first problem (LED blinking when tranferring the .hex file) is related to the uploading process.

I have not any Pickit(2|3) programmer, but I use an USBPICPROG, Open Hardware + Free Software programmer, through hole version builded by myself [1].
I think that all PIC programmers must comply with at least the first three stages of this process, so I supose that I have "catched" the entire issue by its "tail".

Stage1: at startup of the programmer's software, or at the very beginning of PIC connection through ICSP, the programmer's firmware will retrieve de PIC ID and show that in software GUI interface.

Stage2: previous to upload the machine code (.hex converted in binary code, allocated following .hex static addresses), the programmer will reset the PIC and then will ERASE the memory content: FLASH area (program), CONFIGURATION FLAGS, and EEPROM area (data).
At this stage, OPTION register (0x81) becomes cleared = 0x00 (all bits are 0) in PIC16F877/A (EOL) and PIC16F887 (its sucessor), so pull-up weak resistors (bit 7, !RBPU) in all pins of PORT B become ENABLED.

Stage3: the programmer uploads the machine code (program, configuration words, data).
At this stage, OPTION register (0x81) is still cleared.

Stage4 (optional): the programmer will verify the correctness of the code, configuration and data now allocated in PIC.
At this stage, OPTION register (0x81) is still cleared.

Stage5: the programmer resets the microcontroller again, PIC configuration flags are honored
At this stage, OPTION register (0x81) is still cleared.

Stage6: microcontroller beguins to execute the new program.
Of course, if the first instruction (executed only one time as setup) changes the OPTION register (0x81) content, this new value will be used thereafter.


From Stage2 OPTION register (0x81) cleared to 0x00, to the beginning of program execution at Stage6 (changing OPTION register (0x81) to disable pull-up resistors), all PORT B pins are inputs with GROUND reference.

If the PIC and peripheral circuits are externally powered, LEDs connected to those pins will glow dimmed.

If the uploading process is very short (a bunch of Ladder instructions), and Verify code, configuration and/or data has been not enabled in the programmer software options, LEDs glow will be see as a "blink".

But if the code to be uploaded is long, and verify options are enabled, upload process will take much more time (perhaps tens of seconds) and so the LEDS will bright during all that time.

Of course, if you delete your first instruction (MOV 0xff #0x81), LEDs will glow permanently (see my previous reply).

I agree with you, but I think that this pb is not a bug; and it can be "ironed" by a careful hardware design and smart programming technics.

@Alex, @Calubert:
I'm argentinian and speak spanish, of course; but I prefer to write to this forum in english, for the benefit of all the users.
As Jonathan Westhues stated: "Please post in English if possible; this will maximize your chances of a good response".

Best regards,
Thu Jan 24 2019, 11:05:08
(no subject) (by Alex)
thanks for your replies

To Greg Blackwell:

Yeah, you are right i shoulnd´t consider it as plc, i think i want to treat it like that, this ldmicro brings that ladder option and i have to be responsable of taking all safety ways, there are some cases like the one of Magno Medeiros, he uses ldmicro as plc in his work:


and he shares his plc models here:


even Jonathan Westhues{ the first ldmicro developer, said not to use it like that, safety people is more important, but i think many of us will use it for their own, DanielH exaplained clearly why that happens, i think if i enable pull up resistors in arudino and i connect a led to an unused pin with pull up resistor enabled same thing will happen, but i think thats why in arduino and i think in other compilers, they don´t enable pull up resistors by default, maybe i don´t know but change ldmicro no to enable pull up resistors by default but enable them if we want.
Thu Jan 24 2019, 18:23:50
(no subject) (by MGP)
Since we have the possibility to change that with #xxxx it might be better to bring that back as it used to be, pullups default off.
Gilles must be addressed for that ;)
Fri Jan 25 2019, 02:20:18
(no subject) (by José GILLES)
I don't know what you exactly want to do, but "Config bits" field in config panel, which seem to be unused with AVRs, may be used to activate or deactivate pull-ups on port B for instance ?

Fri Jan 25 2019, 12:47:02
loading hex to pic makes port b blink... ERRATA (by DanielH)

My friends, I fear that I've commited an error in my explanation on why loading .hex to PIC makes blink the LEDs connected at unused pins on Port B, as Alex observed.

Reading Microchip docs, I discovered that when erasing program memory, OPTION_REG will be writed with 0xFF value (all bits set to 1) on all kind of Reset signals (POR, BOR, MCLR and others).

Bit 7 of 0x81 OPTION_REG value that controls Port B pull-up resistors, after Stage2 (ERASE PIC memory) will be !RBPU = 1.
Thus, DISABLING pull-up resistors, and remaining at that state until a new value will be writed, during uploading process or by means program code execution.

From docs:
!RBPU bit 7: PORTB Pull-up Enable bit
1 = PORTB pull-ups are disabled
0 = PORTB pull-ups are enabled by individual PORT latch values

So, what is the cause of the "blinking phenomena"?

I think now that is a more complex process:

1. Stage2: ERASE process writes 0xFF value (all bits set to 1) at all TRISx registers, so all I/O pins at PORTx are Inputs; and 0xFF at 0x81 register, so PORTB inputs have pull-ups resistors DISABLED due bit 7 of 0x81 OPTION_REG, !RBPU = 1.

2. So, LEDS are NOT glowing DURING programming process.

3. LDmicro defaults in version > 3.X.X (4.4.x; 5.0.x), when code is uploaded, writes !RBPU = 0, ENABLING pull-up resistors; LEDS are NOT glowing yet.

4. Stage6: After final PIC reset performed by programmer, program execution beggins; LEDS are NOT glowing yet.

5. When PC (program counter) reaches 0x81 OPTION_REG, LDmicro default !RBPU = 0 ENABLES pull-up resistors at PORTB; thus, LEDs beggin to glow.

6. After a very little time, when PC reaches MOV 0xff #0x81 USER instruction, !RBPU = 1 DISABLES again pull-up resistors at PORTB; thus, LEDS ends to glow and remains in this state, THIS is the "QUICK BLINK" that Alex video shows (first part).

7. Of course, if MOV 0xff #0x81 user instruction is deleted, LEDs will glow permanently (Alex video, second part), due 0x81 OPTION_REG remains at LDmicro defaults, !RBPU = 0.

I don't know nothing about internals in LDmicro, so I don't know when 0x81 OPTION_REG is accessed for the first time by execution of LDmicro compiled programs; perhaps by a setup routine (only one time executed at the beginning of the program, using GOTO or similar instruction).

BTW: Neither, I don't know when TRISX.x = 0 instructions are executed, having user declared a pin as an OUTPUT.
I think that, as in LDmicro Inputs and Outputs are static (no change during program execution is allowed), perhaps TRIS operations are in a setup routine at the beginning of the program, too.


I agree with you that changing LDmicro defaults in OPTION_REG to !RBPU = 1, and thus disabling pull-ups resistors at PORTB, will avoid this "blink" problem.

@José Gilles

PIC Configurations Bits in LDmicro are NOT related with 0x81 OPTION_REG (pull-up resistors and other options).

This field writes PICs Configuration Words (CONFIG1; CONFIG2 if it exists in the device).

In PIC16F887, the Configuration bits can be programmed (read as ‘0’), or left unprogrammed (read as ‘1’) to select various device configurations. These bits are mapped in program memory location 2007h and 2008h, respectively.

Address 2007h and 2008h are beyond the user program memory space. It belongs to the special configuration memory space (2000h-3FFFh), which can be accessed only during programming.

Configuration bits at 2007h in 16F87X and 16F88X manages In Circuit Debugger Mode, Low Voltage Programming, Fail-Safe Clock Monitor, Internal External Switchover, Brown Out Reset Selection, Data Code Protection, Code Protection, Master Clear Enable, Power-up Timer Enable, Watchdog Timer Enable, FOSC Oscilator Selection.

Plus, Configuration bits at 2008h in 16F88X manages Flash Program Memory Self Write Enable and Brown Out Voltage Selection.

For example, default Configurations Words for PIC16F887 in LDmicro are 0x2007 = 23E2 and
0x2008 = 0600:
In Circuit Debugger DISABLED
Low Voltage Programming DISABLED
Fail-Safe Clock Monitor DISABLED
Internal External Switchover (Two Speed Startup) DISABLED
Brown Out Reset ENABLED
Data Code Protection DISABLED
Code Protection DISABLED
Master Clear Reset ENABLED
Power-up Timer ENABLED
Watchdog Timer DISABLED
FOSC Oscilator HS (High-speed crystal/resonator)
Flash Program Memory Self Write Protection DISABLED
Brown Out Reset at 2.1V

If user wants to protect his program and data code for reading, must change PIC Configurations bits in LDmicro to 0x06002322 (note that 0x2008 value precedes 0x2007 value), or the Configurations Flags or similar feature in the programmer software, before to upload the machine code.

Also, note that Flash Program Memory Self Write Protection is DISABLED in LDmicro defaults, allowing to use a bootloader to easy and quick programming through UART.
I habitually use TinyBootloaderLin (lcgamboa fork), a GPLv2 application based on TinyPicBootloader by Claudiu Chiculita; the bootloader occupies only 100 words in PIC code memory, and is the smallest for now.

Best regards,
Sat Jan 26 2019, 14:25:09
(no subject) (by José GILLES)

Yes, I have an idea of the use of Config words (bits) for PICs, but as the problem we're dealing with concerns AVRs, and as this field is not used for AVR's, we may use it to select which pull-ups to activate exactly at startup (on ports B+C for instance):

As default value for AVRs Config bits in ld files is 0x0, it could be possible, for compatibility with old designs, to XOR this value with defaut pull-up setting (for inputs only)

ie: If you have 4 inputs PB0-3
Pull-ups by default are PortB= 00001111 in ldmicro
Config bits= 00001100
XOR= 00000011
=> There remains only 2 pull-ups on PB0-1 when running.

If config bits= 0x0, nothing is changed by XOR !

Of course it requires modification of source code...
If some of you think it may be interesting, I can have a look at it.
Sat Jan 26 2019, 16:42:15
(no subject) (by Alex)
i don´t undestand about the source code but as long as pull up resistors are disabled by default as i think it should be like that, comparing with other compilers, even arduino IDE, would be a good idea to try.
Sat Jan 26 2019, 21:18:17
(no subject) (by José GILLES)

I think that disabling completely Pull-ups on inputs may cause some backward compatibility pbs for users.
But with my trick you could disable automatic pull-ups on AVRs or ARMS by using Config bits.

What do other users think of it ?

Sun Jan 27 2019, 07:22:14
(no subject) (by MGP)
Maybe an extra checkbox in the menu "Settings" and default on, or is that too much work?

Personally, I prefer to use them as default 'ON' with pic's
Sun Jan 27 2019, 07:48:09
(no subject) (by Alex)
to DanielH

you were right, doing this(selecting any port b):


led in port b selected doesn´t blink any more when loading hex

also i made this :

|---+ +--------------------------------(/)--|

works the same, so it is the solution


then what about pull up resistors should be disabled by default or maybe what about set all unused pins as output LOW
Sun Jan 27 2019, 21:11:25
(no subject) (by Alex)
sorry i used this (diactivate coil):

Sun Jan 27 2019, 21:14:36
(no subject) (by Alex)
mnm well i don´t know how to say this but apparently:

1)first time loading to your mcu a hex file without:


Unused led blinks in any port B of as we said before.

2)then you load same hex again with:


Unused led blinks in any port B again!!!.

3)then you load same hex for the 3th time again with:


Unused led "doesn´t" blink any more if you keep loading hex with :


but... you return to part 1) if you load hex without:

Sun Jan 27 2019, 21:35:53
loading hex to pic makes port b blink... again! (by DanielH)


My apologies for my delayed reply, I haven't see your news on this topic.


I fear that stating unused pins as outputs and drive them LOW doesn't solve the "blinking phenomena", due this issue is LDmicro v>3.x related (default settings enabling pull-up resistors on PORTB).

As stated in my ERRATA, from the beginning of execution of user program after uploading the new code to the PC (program counter) reaching your first program instruction disabling pull-ups, pull-ups on not declared pins in PORTB (inputs by default) are enabled by LDmicro defaults.

Microchip docs stated that on all kind of resets (after programming, on Power On, on Brown Out, on MCLR reset), OPTION_REG (0x81) = 0xFF (all bits set) -> !RBPU = 1, so disabling pull-ups resistors on PORTB.

IMHO (I don't know LDmicro internals), at the very beginning of program execution, LDmicro performs a kind of one shot SETUP subroutine, PREVIOUSLY to the execution of the first instruction in user program; that SETUP have an instruction clearing OPTION_REG (0x81) bit 7 -> !RBPU = 0 , so enabling pull-ups resistors.

Thus, the "blinking phenomena" theoretically must be observed at every startup, i.e. powering on the PIC and related circuit.
Perhaps it has a very short duration on power on, and only can be observed using an oscilloscope or a digital signal analyzer.


I don't know why you have different results when uploading more than one time an user program that have direct inverted coils declared.

Theoretically, previouly to upload a new code, the programmer will ERASE all code and data memories; but this behavior perhaps is optional in your programmer software (i.e. USBPICPROG have Erase before programming option, along with options to write or not Code memory, Config memory, Data memory and others).
Please, verify if your programmer is erasing the code memory before uploading a new code, perhaps some code memory addresses remains unchanged between uploads, if ERASE process is not performed.

Soon, I will test this phenomena, by ICSP using USBPICPROG, and by serial programming using a bootloader (tinybldlin).
If I can reproduce your issue again, first I will inform you, and then I will burn my brain trying to find why ;-)


Declaring an UNUSED and UNCONNECTED pin as an OUTPUT and driving it LOW do NOT solve the "blink issue".
It is only a safety precaution recommended by Microchip and others, for ALL KIND OF I/O UNUSED PINS (not only for ports that have pull-up resistors).

Of course, if an UNUSED PIN in any user program is PHISICALLY CONNECTED in hardware to any kind of circuit, the status that will be written to this pin as output must be carefully evaluated.

I don't know how you have connected the LEDs on your unused pins: it can be do in two ways: anode to pin, or cathode to pin, of course using it in series with a limiting resistor (R=?).
If the first is used (anode to pin (I guess that is your circuit on PORTB LEDs), configuring pin as output and driving it LOW, LED will NOT bright.
On the opposite (cathode to pin), configuring pin as output and driving it LOW again, LED WILL bright.
So, output status to be written depends on circuit, as I stated before.

NOTE: in LDmicro, RE3/¡MCLR is configured as MCLR with pull-up resistor enabled by default, Configuration Word CONFIG1 (0x2007 = 0x23E2 in PIC16F87x/88x).
If you don't use !MCLR as a Reset and/or ICSP signal (with corresponding circuit), is very convenient to use an external pull-up resistor to avoid unexpected resets.
If you want to use RE3 as input, you must modify Configuration Bits in LDmicro, or using your programmer software, BEFORE to upload your program.

Best regards,
Sat Feb 2 2019, 13:48:37
Post a reply to this comment:
Your Name:
Your Email:
(no HTML tags; use plain text, and hit Enter for a line break)
Attached file (if you want, 5 MB max):