Can the Spark Core trigger the Reset Pin?

Troubleshooting
103

“just like” means “exactly the same” to all students of English, everywhere. More effort is made justifying not improving documentation than the effort which would be needed to fix it. Again.

104

The documentation was and is still written with the knowledge available at the time - it’s clear to see understanding of the actual behavior has increased during the course of this thread.

The docs are available on github and can be contributed by all - should someone discover the documented behavior is not in line with the actual behavior they are warmly encouraged to submit a pull request to have the docs updated to reflect omissions or new knowledge.

@psb777 consider dogfooding your own advice - the time you spend admonishing the efforts of others could instead be put to use improving the docs.

4 Likes
105

@ScruffR Do you have some test code that shows millis() not resetting when using System.reset()? I just tried this code and it always reports 101ms for me, i.e. it's resetting millis() with System.reset();

#include "application.h"

SYSTEM_MODE(MANUAL);

uint32_t lastReset = 0;

void setup() {
	lastReset = millis();
	pinMode(D7, OUTPUT);
	digitalWrite(D7, HIGH);
	delay(1000);
	digitalWrite(D7, LOW);
	delay(1000);
	Serial.begin(9600);
	while(!Serial.available()) Spark.process(); // Start serial terminal & Press ENTER
	Serial.print(lastReset);
	delay(1000);
}

void loop() {
	// Reset after 20 seconds of operation
	// ==================================
	if (millis() - lastReset > 20000UL) {
		System.reset();
	}
}

I feel it's good coding practice to initialize your variables to a known state. if a test against that variable runs before it is set, unexpected things will happen. While that example clearly shows lastReset being re-initialized to equal millis() on the next effective line, they don't really execute right after each other. Once you start adding more and more code to this example, perhaps you'll add a test against lastReset before it's set equal to millis(), maybe not... but if you initialize your variables to a known value at least you have one less thing to keep track of in your code.

I would also argue that the documentation is correct. System.reset() calls NVIC_SystemReset() which forces a reset of the uC. A soft reset should be very similar to a hard reset assuming we are clearing any unused RAM on initialization. This is also a good argument for initializing your variables, because even if we didn't... you are. The only thing NVIC_SystemReset() does not reset is the debugging hardware and any associated registers, AFAIK. If anyone has a super in-depth explanation of NVIC_SystemReset() on the STM32F103 I'd love to see it... I searched for a while through all of the documentation and it says very little. Even on ARM's website, and books on the ARM Cortex-M3.

2 Likes
107

Thanks for trying this out @BDub - there were enough people in the thread seemingly confirming the result that I didn’t think to test it out myself.

I can say for sure that variables are reinitialized - since this is part of the system reset handler. The RAM that is initialized includes all variables, whether explicitly initialized in the code or not (variables without an explicit initializer are initialized to 0.)

So, is there a SSCCE that shows that millis() isn’t being reset?

btw, regarding initializing - static variables are always initialized before use - the variable initialization is some of the first code that is ever executed by the system shortly after a reset, so there’s no chance of being able to use an uninitialized variable.

2 Likes
108

@BDub, @mdma and @AlanSparkMan, sorry folks for the confusion I’ve caused :blush:

I should have checked this before assuming what I’ve seen in the past in a similar case on some other micros would apply for the ARM micros too.

My bad and I’ll be more careful in future and I’ve edited my posts above to kill this misconsception before it manifest in other peoples minds just the way it did in mine :worried:

Sorry, again :blush: