Added mod to avoid reset of Arduino when USB serial connection is made

THE NORMAL BEHAVIOR OF ARDUINO IS TO RESET WHEN A USB CONNECTION OPENS

The serial communications supported over USB includes the DTS/DTR signals. When a serial connection is instituted by an RS232 device (such as USB on a laptop), signals are toggled that the Arduino detects and issues a reset to itself. 

This restarts the 'sketch' running in the Arduino so it is in a known good state, but also watches for a specific data stream at the beginning which is targeted at the bootloader. This is how the development environment uploads new code to the Arduino. 

THIS LEAVES CONTROL SIGNALS IN UNDEFINED STATE FOR A SHORT PERIOD

While the processor is reset and running under the bootloader code, the state of various input-output pins on the Arduino is not controlled by your sketch. They assume some default values until you code begins running to set the pins up correctly. For example, an output pin is by default in logic low state. 

The 1130 makes wide use of inverted logic, where a logic low signal is the true state of a signal. In particular the signal -Req CS Level 1 when pulled to low triggers a cycle steal to access memory on behalf of our loader. Thus during the reset time we fire off a spurious cycle steal with undefined word value and undefined core memory address.

This is undesirable. Somebody could fire up a terminal while the 1130 is still running a program, causing a random write into memory. My logic in the core loader will not request a cycle steal if the CPU is running, but the pin activity during the reset period is not bound by that protection. 

CAPACITOR ACROSS RESET WILL BLOCK THE RESET FROM THE SERIAL CONNECT

The Arduino routes the reset line out to one of the pins around its periphery, where a .1uf capacitor can be soldered with the other end hooked to the nearby ground pin. This 'eats' the short reset pulse from the USB serial connection, preventing the sketch from restarting. It also prevents the Arduino bootloader from running thus an upload of new code will not occur as it usually does from the development environment. 

Comments

Post a Comment

Popular posts from this blog

Bizarre behavior detected in a Raspberry Pi Pico based design and partially understood

ORIENTATION OF THE PRODUCT CAN CAUSE THE PI TO FREEZE AT STARTUP This particular product with a Raspberry Pi Pico would not boot up when sitting flat on the table in its normal orientation, but if tilted or turned it would come right up. When I hooked up a USB serial connection to the debug header, it worked fine even flat on the table.  INVESTIGATION BY DESIGNER AS WELL AS ME I first assumed that I had introduced this problem in the product, but happened to describe it to the maker who was able to reproduce it reliably. I continued to try variations to determine whether it was pressure on a board or component that caused it. I also searched the web for any reports that might cause Pi Picos to fail to boot based on orientation, but found nothing.  The designer found signals introduced on a serial connection trace when sitting in the normal (failing) orientation but not injected when rotated or otherwise turned. Traces were routed from the UART0 on the Pico to a header, for use...
Read more

Incompetent coders - the frustration of using Vivado to build FPGA designs

IDIOT SOFTWARE MUST BE RESTARTED CONSTANTLY TO SEE INPUT FILE CHANGES When I update a source file, often Vivado is somehow working from a cached copy and never notices the changes. It is highly frustrating to fix an issue, rerun a Linter or Synthesis and get the same old errors. The only solution is to shut Vivado down and restart. I remember hitting this many times in past years as I worked with the toolchain, but it has changed from sporadic to nearly constant failure to see the changed timestamp. I can't be the only person running the toolchain under Windows, yet this kind of bumbling misperformance has been a feature for years. 
Read more

Found correct mod for the Arduino Mega 2560 to avoid powering it from USB

Image
USB HANDLING CIRCUITS IN THE MICROPROCESSOR REQUIRE USB VCC TO RUN The reason my first attempt failed, simply removing the poly (resettable) fuse, is that the fuse is between the USB connector and the microchip which needs the USB VCC connected. I had to reinstall the fuse.  BETTER CHANGE IS TO REMOVE A MOSFET THAT ROUTES POWER The Arduino uses a power mosfet and a comparator to decide when the external power is adequate to run the board, disconnecting the USB VCC from the board. It does leave that wire connected to the USB circuitry in the chip, however. With the transistor removed, the USB power never gets to the board so it is always powered by the external (1130) power. This means the board powers up and down with the main system, whether or not a USB cable is connected to anything else. When the board is powered up, the cable is active as a serial connection, exactly what I wanted to happen.  In the picture below, the green circle shows the reinstalled polyfuse. The red c...
Read more