The boot time is long.

[secupol]

Maybe, below sleep code is not needed. Because it is added for input voltage settle time before call this function.

int mcpwm_foc_dc_cal(bool cal_undriven) { // Wait max 5 seconds for DRV-fault to go away int cnt = 0; while(IS_DRV_FAULT()){ chThdSleepMilliseconds(1); cnt++; if (cnt > 5000) { return -1; } }; //chThdSleepMilliseconds(1000);

[Teslafly]

Looks like this checks to make sure the fault output pin on the drv is cleared before it finishes starting up. This probably suppresses bad things happening in the main commutation loop if it starts without the drv fault cleared. (at the very least you trigger a not real error message)

If the drv fault clears fast this should continue past quickly.

[surfdado]

I also am under the impression that beta45 takes something like 50 percent longer to boot than beta25. I haven't stop-watched it but I have a beeper that goes off when boot is complete so this is how I noticed... I will check for the IS_DRV_FAULT to see if that applies in my case

[surfdado]

Did a little more digging on this. On my LittleFOCer it looks like the drv fault clears in less than half a second. The biggest culprit for beta40++ boot lag is the newly introduced ADC calibration (3 seconds!!) easily doubling the boot time. Luckily it can be turned off to get the boot time back to pre-beta37 levels

[Teslafly]

Is there a reason to do the adc calibration every time? or is it enough to calibrate it once every xx boots (or at 0 current command) and store it to flash to be reused for fast boots? The major zero point offset influence is going to be temperature. Which varies significantly through the operation of the vesc.

[surfdado]

One of the many mysteries... not sure what makes this particular calibration different from others to warrant doing it on each boot

[Teslafly]

It's probably "safest" and easiest to do it every boot over trying to come up with a way to do it only when needed. For most applications boot time is not significant. There are other 100+msec hard-coded delays in the boot path that don't help. (at least the last time I analyzed it.) The chip also verifies it's entire flash before starting the main thread.

// from main.c startup path
	chThdSleepMilliseconds(100);

	hw_init_gpio();
	LED_RED_OFF();
	LED_GREEN_OFF();

	timer_init();
	conf_general_init();

	if( flash_helper_verify_flash_memory() == FAULT_CODE_FLASH_CORRUPTION )	{
		// Loop here, it is not safe to run any code
		while (1) {
			chThdSleepMilliseconds(100);
			LED_RED_ON();
			chThdSleepMilliseconds(75);
			LED_RED_OFF();
		}
	}

But for boards that have roll to start features a long boot time is no good. Would a boot time limit target be a good idea for a very targeted issue? 1 second would seem to be reasonable for push to start applications if an attempt was made to cut down boot times (fast boot option that skips long items?)

[surfdado]

I use a buzzer that I trigger when the board is ready (Onewheel application) - so I know when it's safe to hop on. This is also how I noticed the sudden doubling in boot time when upgrading from beta37. But roll to start is probably the toughest use case out there... With the latest 5.3 beta you better hope that you're not doing roll to start on any hills...

[nyxrobotics]

Hello, For me a 5 second startup delay is too long and I want it to be about 1 second. If anyone has tried this problem, I would be glad to get a coding guide.