I can not get reception but I can transmit between my PIC and a NEXTION display.

When I communicate my PIC with the simulator of the NEXTION in my PC through a FTDI232 everything works OK.

On another board (picclicker) with my PIC and the NEXTION everything works OK.

With an oscilloscope I can determine the voltage values in the lines:

PIC and PC (tx: 3.3 volt, rx: 5 volt, seen from the pic)
PIC and NEXTION (tx: 3.3 volt, rx: 3.3 volt, seen from the pic) on the board that does not work.
PIC and NEXTION (tx: 3.3 volt, rx: 3.3 volt, seen from the pic) on the board that does work.

picclicker is a board of evaluation (the other board, where serial reception does not work is the electronic board that I developed).

You have two boards, the MikroElektronica PIC clicker board and
the board you made. One works. The other one doesn't work.

Compare the two boards until you find the problem. Compare the
traces. Compare the regulated voltages. Compare the amount and
placement of bypass capacitors. Compare everything.

Ttelmah

Joined: 11 Mar 2010Posts: 12736

Posted: Sun Feb 25, 2018 3:15 pm

Have you done a basic 'flash an LED' test on the board and verified it is running at the right clock rate?. reason I query this is these two entries:

Code:

#FUSES INTRC_PLL_IO

#use delay(clock=48000000,crystal=16000000)

These disagree with each other as to what clock source you are running.

AndresRam

Joined: 27 May 2017Posts: 16Location: Colombia

Posted: Sun Feb 25, 2018 3:30 pm

OK, the new board work ok with another routine, another peripherals.

The transmission from pic to Display is OK, I see in nextion display the info send for the pic,

any question:

#int_rda2 work well with my configuration of RS232?
my RS232 configuration is soft or hardware?

Although the strange thing is that the same code works well in MICROE board in the same pins of tx and rx !!!

what's more, my board works well (both reception and sending) when I simulate the nextion display with a virtual terminal on my PC through an FTDI rs232 to USB module adapter

PCM programmer

Joined: 06 Sep 2003Posts: 20172

Posted: Sun Feb 25, 2018 5:52 pm

AndresRam wrote:

#int_rda2 work well with my configuration of RS232?

You need one improvement. Add the ERRORS parameter to the
#use rs232() statement. Example:

Code:

#use rs232(baud=9600,UART2,stream=DISPLAY, ERRORS)

AndresRam wrote:

my RS232 configuration is soft or hardware?

Look at the .LST file for your program. If the ASM code in the #int_rda2
function is talking to hardware registers, then the hardware UART is used.
Example: In the code below, you can see that the code is talking to PIR3
and RCREG2. This code is using the hardware UART.

No, that is NOT the solution. That's a symptom; an indication you are on to something. A system should never, under normal working conditions, have any serial communications errors. Now you have to find out why the UART was giving errors: why is that? Timing problems? Noise? Incorrect voltage levels? Incorrect framing (number of bits, stop bits etc.)? Receiver overrunning (new characters coming in before cdoe has dealt with old one or ones)? Then you correct that problem. Then you've got a solution.

AndresRam

Joined: 27 May 2017Posts: 16Location: Colombia

Posted: Wed Feb 28, 2018 5:02 pm

Thank very much,
Of course, you are right in fact. The following happens: when feeding the Nextion Display for the first time, I do not know what "garbage" sends to the microcontroller. but only when it is turned on, for the rest there is no "garbage" to worry about. I thought about solving this by doing a small restart with a WatchDog in the microcontroller to give time for the Nextion to send the "garbage", but only with the ERRORS was enough.

PCM programmer

Joined: 06 Sep 2003Posts: 20172

Posted: Wed Feb 28, 2018 6:42 pm

One possibility is to add a 10K pullup resistor to the Rx pin of the PIC.
Connect the pullup to the same Vdd voltage as the PIC.
If the Rx pin is floating for a while during power-up, the PIC could receive
garbage. The pullup may stop this problem.

Ttelmah

Joined: 11 Mar 2010Posts: 12736

Posted: Thu Mar 01, 2018 1:06 am

Lets expand a fraction on what PCM_Programmer has said.

It is quite common for serial devices to take longer to wake up than the PIC.
Even the 'standard' MAX232 does this. Result is that during the first few mSec after boot, the PIC can/will receive garbage.

First thing that can help is the pull-up resistor. Tries to ensure that if the device hasn't actually switched it's output 'on', the line will go high, rather than floating. This is also necessary for any device who's output can go 'tri-state'. Things like RS485 buffers for example. Not having this can cause just the odd erratic problem that is hard to find...

Then, if the device is something that shouldn't send data before you 'ask' it, then at the start of the code, flush the input buffer, before enabling the RS232 interrupt.

On 'ERRORS', the general rule is that either your code needs to test and handle errors, or you should always have this in any RS232 setup that uses the hardware UART.

temtronic

Joined: 01 Jul 2010Posts: 5878Location: Greensville,Ontario

Posted: Thu Mar 01, 2018 5:51 am

As both PCM P and Mr. T point out, you need to clear the UART and your rcv buffer.