PIC24 pcd bootlader

[georpo]

After more testing:

[Ttelmah]

Add a setup to disable the comparator:

setup_comparator(NC_NC_NC_NC);

If you look, the pins that don't work have in common that they use pins
attached to comparator 1. You've not tried RX on B3, which would be the
other pin with the same comment.
If you look at the pin priority list, the pin has the analog input as the
highest priority (but the compiler normally turns this off), then the
comparator, and below this the RP option.

[georpo]

I tried it. No change.
Also I tried to disable analog inputs and I2C module.
Unfortunately B3 has no track on the board and it difficult to solder a wire to the small QFN28 pins.

And again, why does it work when I do:

[Ttelmah]

I would suspect something like the input threshold on the problem pins
is fractionally different to the others. Possibly if you look closely
(actually recording the data when you do the putc=getc code), you will
find that on the problem pins there are a couple of characters of 'noise' at
the beginning, that doesn't happen on the other pins. Result is then a
problem with the received data for the bootloader....

There is a generic 'issue', that all the pins on these PIC's are ST inputs
(Schmitt). Now a lot of devices do not reliably give outputs that go
high enough 100% reliably into such inputs. It'd only take individual
pins to have a 0.05V higher 'input high' threshold, for problems to
appear. Something like a 2K2R pull up resistor on the signal feeding
the RX pin might make a very significant difference.

[georpo]

I soldered a pullup on the B3 RX pin but no change again.
My test works but bootloader does not.
It is getting really annoying.

More tests:

[georpo]

I swapped the pins and use B6 for U1RX.
I already modified the loader.c to write the PIC memory from the board's 2MB flash and all is working good.
I guess I will never find out the reason of the problem.
Ttelmah once again thanks for the generous help end effort.
_________________
George.

[Ttelmah]

I must admit to 'hating' this sort of fault. Every likely physical issue is
checked, and no solution found.

There is though a possibility.

Another pin on this chip is reported in the errata as having an issue, where
the peripheral does not automatically override the normal I/O functions.
If this was happening, this could prevent the UART from working.
There is also an errata where RA0 won't operate as an input, if the
open drain output is enabled on RB0. Again it is possible that other pin
pairs may have similar problems.

So it may be that you are seeing a 'variant' of one of these errata....

the putc=getc test is a very good one, but does have significant differences,
in particular the timing, since it won't actually check the getc again
immediately while it performs the putc, while the real code in the
bootloader, does sequential getc's without any putc. Again there is a
reported issue with the transmit buffer flag, and this might cause an
oddity, but since this is with the UART, I'd have expected this to show
whatever pin was used...