<< return to Pixycam.com

Signature data being lost

Pixy Hardware
#21

I haven’t seen this. There is a boot check that goes through all of the flash records and verifies their checksums. If it finds something that’s not correct, it formats and starts over. I assume that’s what’s happening, but I’m not sure why it is finding bad checksums.

I’ll look into this… thanks!

#22

Hi Rich

Thanks.

My initial assumption was that it was temperature related since we were seeing it when we switched on the Pixies round 0C in the morning. However we also then saw it happening at much warmer temperatures and others above also mentioned seeing the problem at temperatures above 0C.

My next guess would be it’s a power regulation issue, where during power up of the microcontroller and Pixy with the Pixy being powered by the microcontroller there is sometimes a power glitch specifically while both are powering up.

Maybe if you connect a Pixy to an Arduino and power cycle the system a number of times with a debugger attached to the Pixy you’ll be able to trigger the condition.

Can you point out the location of the boot check code in Github so others can also take a look to see if they happen to spot anything?

Cheers

#23

Yeah, the descriptions around this issue sound like there is something pointing to power — if the processor and/or flash browns out during the check (low battery, etc), a flash parameter format will take place.

Thinking about this some more, this isn’t a good choice. It’s better to read the wrong data from flash than to erase/start over, which results in the loss of important data (bad).

here’s the code in param.cpp

int prm_init(Chirp *chirp)
{
	// check integrity
	if (!prm_verifyAll())
	{
		// if we're corrupt, format, start over
		prm_format();
		return -1;
	} 

	chirp->registerModule(g_module);
		
	return 0;	
}

And here (attached) is a firmware version with the code disabled for y’all to play with/test. Let me know how it goes. :slight_smile:

#24

Thanks Rich

In this case, i.e. verification fails does that mean the Pixy starts up with default values, i.e. SPI, no color signatures but at least it doesn’t format the flash so on a subsequent startup it will more than likely succeed and start with the last set of values that were set?

Or depending on at what stage the verification fails will it potentially mean that the Pixy will startup with some of previously saved parameters and defaults for the others, e.g. it may startup with the correct communication interface but the color signatures may be empty for this particular startup?

In other words if we notice this, all we need to do is a power cycle and we don’t have to re-setup the Pixy in terms of interface protocol, color signatures etc.

I guess the other option for now assuming very intermittent brown outs during startup is to loop say 3 times if the verification fails with say a 1 second pause in between.

Cheers

#25

Yes, if verification fails, it wipes all parameters and restores default values.

I’m interested in how the new firmware above changes things. There is either an error during read or error during write to flash. Based on the feedback we receive from the new version, we’ll shed more light on what’s going on.

thanks!