So we have a product that we use the UNO in. We are finding that we have systems that sometimes dont respond to the "home" command which is
asm volatile ("jmp 0");
I was able to reproduce the problem on one of our systems. What is funny though, 3 out of 4 times it will not seem to respond to Asm volatile (when invoked auses a motor to home) but it does actually work 1 out of 4 tries where i can see the motor move. Its not consistent. Why?
Then I just reprogrammed the same UNO (edit: and also, from the SAME IDE) and it was fine. The system was not even rebooted. I ran it about 20 times in a row without a problem.
Any idea what can cause? Really need some help with this as we have systems we have shipped to customers that need to be fixed.
This IDE is one in which does not need to be installed but is run from a set of files. The previous one I downloaded about 2.5 years ago and was installible.
We have used this in our products for about 6 years so cant think of what is new. Its a new IDE that i dont normally use though. This one does not need to be installed which is why I downloaded it.
The EE who worked here before me said sometimes you have to program them 2 times. Not sure if this is related? Why would an UNO have to be programmed 2 times?
That is not a "home" command, it restarts execution of your code form the beginning, without resetting the hardware. The indeterminate state of the hardware may be causing your problem, since a different version of the IDE / compiler may result in slightly different machine code, different use of processor registers, location of variables in memory, etc.
A better method is to activate the watchdog timer, then go into an infinite loop so that it times out and does a full reset of the processor, but it is much preferable to just write code that does not need this type of drastic restart.
yes, i did not provide a clear function of what we use asm volatile for. We use asm volatile to induce a motor to go a home position upon the microcontroller resetting to the 0 line of instructions. I know there is a problem with the reset when the motor does not move when it should.
Why can i reprogram the same UNO with the same IDE, not rebooting, and then it works?
Why does it not work consistently?
What causes your code to execute the jmp 0 instruction? Is it always caused by the same thing at the same point in the program, or is it something like a button press or a specific condition being met? The specific state of the processor, the values present in the processor registers, the state of the I/O pins, etc, can affect how the code behaves, because the jmp 0 is different from a hardware reset where the state of the processor and I/O ports is known.
My admittedly very limited experience with Arduino Uno R3 has shown me that even the hardware reset button does not restore the processor to out of the box state. I ran the “Blink” sketch as written and the onboard LED blinked. I then modified the sketch to blink output #9.
When I downloaded the sketch output 9 blinked as expected but output 13 was still on. I hit the reset button. No change. 9 blinked output 13 was still on. I then modified the sketch and added a line in setup to turn off output 13 without a line to define 13 as an output. When I downloaded the sketch thirteen was off and nine blinked.
My takeaway from this is that all registers that are being used need to be explicitly configured and initialized at every startup, just as is my habit when writing assembly for other microcontrollers and microprocessors.
I am guessing that this is omitted from the bootloader intentionally in order to save the not insignificant amount of EEPROM that this would take. The R4 may be different.
The LED is driven through an OP AMP configured as a voltage follower. Since pin 13 is configured as an input, and the only connection is the high-impedance input to the OP AMP, the pin can float to a sufficient voltage to turn the LED on. Not sure why writing a LOW to pin 13 turns it off, but writing a HIGH activates the internal pullup and will definitely turn the LED on, leading to some confusion because it is possible to blink the onboard LED without declaring pin 13 as OUTPUT.
Hi David
A serial command is sent which invokes "asm volatile" command. It is sent around the same point in time of each motion control cycle.
The " jmp 0" is the idea that the first line is the start of the program so the program resets itself
This command is something the previous engineer to me put in 8 years ago.
Only having problem now. I'd hate to change it when it's worked for so long really want to understand more first. Especially as we have shipped system that may need to be updated
There are older versions of the IDE that you can use if that will solve your immediate problem. But going forward you will want to make a proper job of it.
Yes it will be if your code has done nothing to change it. That pin is used by the boot loader to show a download is in progress.
There is a big difference between a micro controller and a micro processor. Controllers tend to use a modified Harvard Architecture where the code is in a different address space than the data. So you can't mistake data for code like you can on the Princeton Architecture. The modified Harvard Architecture is that there is one page of memory that can access the code space, and thisis where the boot loader lives.
So 8 years ago you were sold a hack pure and simple. It is very easy to code without using this hack or without using a "goto" call, if only you structure your code correctly.
There should be no need to replace already shipped systems if they work correctly with this old hack.
Going forward you might want to extract the HEX file from one of your working systems and program your new systems with that.
I suspect the change came about by a change in compiler, or the boot loader you are now using.
You are correct. It’s in flash memory. A type of EEPROM that the processor itself cannot modify.
Pretty much the point I was trying to make. It still illustrates that not everything is restored to out of the box condition by performing a hardware reset.
Regardless of architecture you still have to initialize all peripherals explicitly at startup including the data stored in their respective registers.
I don’t understand why you bring up these minor points when I was only trying to illustrate how things can be left in an arbitrary state on a hardware reset, which I believe I have accomplished.
Harvard architecture, Princeton architecture, community college architecture aside, I can still read a data sheet and figure out how to make it run and figure out why it doesn’t.
No that is wrong, read what you said again. A hardware reset will set all the pins to inputs. It is what happens after that hardware reset, ie the boot loader that leaves pin 13 as an output.
Also what is the out of thebox state anyway? All Arduinos ship with a blinking LED sketch already loaded into them, so correct the reset button will not restore that sketch, but you wouldn't want it to would you?
Well I am not convinced you have.
There is a lot more to the Arduino development system than you will find in the data sheet.
I will not divert this thread from its original intent any further. I do know that after I loaded a sketch to turn output 13 off it never stayed on when loading subsequent sketches.
