View previous topic :: View next topic |
Author |
Message |
georpo
Joined: 18 Nov 2008 Posts: 278 Location: Athens, Greece.
|
|
Posted: Thu Oct 08, 2020 12:14 am |
|
|
After more testing:
Code: |
//#pin_select U1RX = PIN_B2 //NOT working
//#pin_select U1RX = PIN_B8 //working
//#pin_select U1RX = PIN_B10 //working
//#pin_select U1RX = PIN_B14 //NOT working
//#pin_select U1RX = PIN_B9 //working
//#pin_select U1RX = PIN_B7 //working
#pin_select U1RX = PIN_B5 //working
|
Something weird.
All the above were tested for reception first! _________________ George. |
|
|
Ttelmah
Joined: 11 Mar 2010 Posts: 19245
|
|
Posted: Thu Oct 08, 2020 12:50 am |
|
|
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
Joined: 18 Nov 2008 Posts: 278 Location: Athens, Greece.
|
|
Posted: Thu Oct 08, 2020 12:58 am |
|
|
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:
Code: | while(1) putc(getc()+1); |
Edit:
I soldered a wire to B3. It is working with my send/receice test but NOT working with the bootloader. I mean, like the rest, it receives, I get the message "resetting" but the loop at 0xC00 does not change. _________________ George.
Last edited by georpo on Thu Oct 08, 2020 1:20 am; edited 1 time in total |
|
|
Ttelmah
Joined: 11 Mar 2010 Posts: 19245
|
|
Posted: Thu Oct 08, 2020 1:15 am |
|
|
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
Joined: 18 Nov 2008 Posts: 278 Location: Athens, Greece.
|
|
Posted: Thu Oct 08, 2020 1:27 am |
|
|
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:
Code: | //#pin_select U1RX = PIN_B2 //NOT working
//#pin_select U1RX = PIN_B8 //working
//#pin_select U1RX = PIN_B10 //working
//#pin_select U1RX = PIN_B14 //NOT working
//#pin_select U1RX = PIN_B9 //working
//#pin_select U1RX = PIN_B7 //working
//#pin_select U1RX = PIN_B5 //working
//#pin_select U1RX = PIN_B3 //NOT working
//#pin_select U1RX = PIN_B6 //working
#pin_select U1RX = PIN_B13 //NOT working |
_________________ George. |
|
|
georpo
Joined: 18 Nov 2008 Posts: 278 Location: Athens, Greece.
|
|
Posted: Fri Oct 09, 2020 2:11 am |
|
|
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
Joined: 11 Mar 2010 Posts: 19245
|
|
Posted: Fri Oct 09, 2020 2:23 am |
|
|
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... |
|
|
|