Why doing a loop-back test requires pulling the RESET low?

Go To Last Post
13 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Here are instructions for doing a loop-back test, which I used to send Serial data to Arduino Uno and Read them back at the same time on my terminal:

https://forum.arduino.cc/index.php?topic=73748.0

 

My question is, why does RESET have to be connected to ground? Does the Tx/Rx lines not connect to the D0 and D1 pins at all times?

I thought RESET is for resetting the MCU registers as well as putting AVR in ICSP programming mode. What does RESET do in this case?

This topic has a solution.
Last Edited: Wed. Jul 1, 2020 - 02:04 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

In that test, it looks like they are testing the USB-TTL serial connections, by "looping back" the TX to RX pins, which also connect to the M328 on the UNO board.

By holding the M328 in reset, it will not try to "talk" or listen at the same time the loop back test is in progress.  While in reset, the M328 will remain in a Hi-Z condition, and not run.

Hope that helps.

 

Jim

 

 

FF = PI > S.E.T

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

But holding the M328 in reset also puts it in ICSP programming mode, which should put it in some "listening" mode?

 

When the reset is not low, I cannot see the data echo'ed back, is it because Tx/Rx are not connected to the D0 and D1 anymore?

Last Edited: Tue. Jun 30, 2020 - 07:48 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0


avruser1523 wrote:
But holding the M328 in reset also puts it in ICSP programming mode, which should put it in some "listening" mode?

It only enters ICSP programming mode, if commanded by data on the ICSP data line, otherwise it just waits for an ICSP command or waits for a release of the reset line.

Here is a small portion of the UNO R3 schematic:

The red circle shows the TX/RX lines coming from the USB-TTL bridge through 1K resistors to Arduino pins 0 and 1, and also to the M328 RX/TX pins.

With the M328 in held in reset, it is in essence out of the circuit during the test.  The loopback would need a jumper between Arduino pins 0 to 1 to make the "loop back" happen.

Now using the Arduino Serial Monitor, or any terminal emulator, typing any characters will be "echoed" back to the terminal for a successful loop back test.

 

Jim

 

 

FF = PI > S.E.T

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

The loopback would need a jumper between Arduino pins 0 to 1 to make the "loop back" happen.

What do you mean by that? (sorry not an electrical engineer). Tx/Rx lines seems to be permanently connected to the Arduino pins 0 and 1, so why does `M328` being there or not (reset or not) matters?

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

avruser1523 wrote:

 

What do you mean by that?

Simple, the "Loop back" test is testing the USB-ttl bridge, by connecting its TX pin to its RX pin, you will see what you type when using a terminal program, such as the Arduino Serial Monitor.

You want to take the M328 out of the test, because it too is connected to the TX and RX pins, and you don't want two devices both trying to drive the bridges RX line at the same time, bad things can happen when one wants to drive it high while the other wants to drive it low! 

Now once you know your serial bridge is working, remove the "loopback" jumper, remove the reset jumper.  Now the serial monitor can talk/listen to the M328.   You have now proven one side of the comm link works, so if a problem still exists, it must be with the program in M328.   You always want to solve only one problem at a time.  The Loop Back test proves one end works and is now known to be good.  (if the loopback fails, then this problem needs to be solved first before ANY other issue can be addressed) Why you ask (anticipating the next question)

Because the serial line is used to load programs into the M328 via the bootloader, if the bridge does not work, you will not be able to load programs this way, only via the ICSP method.

The boot loader is way easier to use, as all you need is the uno card and a usb cable, no other equipment is required to load programs (sketches).

OK?

 

 

Jim

 

FF = PI > S.E.T

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

almost clear. You mentioned "because it too is connected to the TX and RX pins, and you don't want two devices both trying to drive the bridges RX line at the same time".

 

When Not in reset mode and assuming I have not programmed Arduino pins to output anything, why would M328 be driving Rx/Tx, it might be listening on it but it shouldn't output any pulses? does it? in which case it shouldn't matter if it's there or not?

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

When Not in reset mode and assuming I have not programmed Arduino pins to output anything, why would M328 be driving Rx/Tx, it might be listening on it but it shouldn't output any pulses? does it? in which case it shouldn't matter if it's there or not?

Nobody who wrote that article knows about you or followed you around town to see what you were up to with the chip.  By holding reset, they 100% KNOW that the m328 will have no interfering effect.   The Atmel patrol will be swinging by to verify all of your variables are in alphabetical order.  

When in the dark remember-the future looks brighter than ever.   I look forward to being able to predict the future!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

No I a actually tried those steps Without grounding the reset pin and echo did not work so was wondering how Tx/Rx could be in use by M328 if it's not outputting anything.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 1

How about the bootloader in the M328? It will be wanting to use the serial port.

Last Edited: Wed. Jul 1, 2020 - 04:59 AM
This reply has been marked as the solution. 
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 1

avruser1523 wrote:
When Not in reset mode and assuming I have not programmed Arduino pins to output anything, why would M328 be driving Rx/Tx

As kartman said, the bootloader is using the pins, as least for a short time after release of the reset pin. 

When the reset pin is high, the mpu is always running a program (unless it is in sleep mode), which could be using the USART and thus driving the TX pin.

Holding the reset pin low, insures the mpu is stopped and all pins are disabled, freeing them for the loopback test.

 

Jim

 

 

FF = PI > S.E.T

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

avruser1523 wrote:

...and assuming...

 

Making assumptions is why we see so many questions here on Avrfreaks.

#1 Hardware Problem? https://www.avrfreaks.net/forum/...

#2 Hardware Problem? Read AVR042.

#3 All grounds are not created equal

#4 Have you proved your chip is running at xxMHz?

#5 "If you think you need floating point to solve the problem then you don't understand the problem. If you really do need floating point then you have a problem you do not understand."

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 1

avruser1523 wrote:
assuming I have not programmed Arduino pins to output anything, 

As avrcandies suggests, the whole point of this test procedure is that it makes no such assumptions!

Top Tips:

  1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
  2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
  3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
  4. Difference between a crystal, and a crystal oscillatorhttps://www.avrfreaks.net/comment...
  5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
  6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...