Everything seems slower than it should be after flashing?

[ben-hawks]

Hello!

So, as far as I can tell, I've managed to successfully flash FreeExpression on my CREX001, compiled the firmware (without any changes) via Microchip Studio 7.0, uploaded via AVRDude and the SparkFun Pocket AVR Programmer via:

avrdude -c usbtiny -p m1281 -U flash:w:FreeExpression.hex:i -U lfuse:w:0x42:m -U hfuse:w:0xD9:m -U efuse:w:0xFF:m

avrdude -c usbtiny -p m1281 -v -v -v -U eeprom:w:freeexpression.eep

and set the fuses as mentioned in #18 via the first command. (Though the extended fuse comes back with an error saying it's actually set to 0xF7, and I can't get it to actually set to 0xFF, im unsure if this is really an issue and proceeded anyway)

but while everything in theory works... It's very slow? Seemingly as if the clock speed of the MCU is some fraction of what it should be? Everything from the OLED updating, to the motors moving, to the response after a button press feels like it's a lot slower than it should be, and from what I saw in #16 's video tutorial (thanks @wildseyed by the way! I used your method of pulling the plastic housing off the ISP pins and it worked well, and the video was really helpful in general too!) it is actually slower than what should be happening.

I'm at a bit of a loss here in terms of what could be causing this, other than maybe a failing oscillator (I haven't checked this yet). In some desperate attempt to try something, I ordered a replacement power supply, as the one I was using is 19V 3.5A and the correct one is supposedly 18V, though I would be surprised if a 1V difference affected things this much, and didn't seem to have this effect on the stock firmware (for the little time I played with it after purchasing the machine at goodwill).

Anyway, thanks for the project in the first place, and thanks for any help you might be able to give! I can provide a video of what I mean later on/if it would be helpful.

[wildseyed]

There are at least three possibilities: (1) What you are suggesting is the problem (not likely), (2) The way the files are being generated is creating lots of very short segments, and processing these is causing the system to go very slow due to acceleration/deceleration for each move, (3) The speed is being specified in the file somehow.

Can you provide a copy of the file you are testing with?

[ben-hawks]

There are at least three possibilities: (1) What you are suggesting is the problem (not likely), (2) The way the files are being generated is creating lots of very short segments, and processing these is causing the system to go very slow due to acceleration/deceleration for each move, (3) The speed is being specified in the file somehow.

Can you provide a copy of the file you are testing with?

So, this is the confusing part to me, and what makes me suspect something being wrong, but this is without any file that I'm cutting. Just booting, homing, jogging, loading/unloading, refreshing the oled, etc. is extremely slow. Here's a video of what I mean: https://www.youtube.com/watch?v=YCIrorCecB0

The video cuts off somewhat through the homing cycle, but what I've noticed happen here is that it hangs forever (well, for a long time) and I need to power cycle the machine to continue. I'm imagining this is somehow connected to everything being too slow, and potentially interfering with whatever feedback it's using to detect it's at 0.

[wildseyed]

OK. Yeah, that's a hardware issue. It's like the clock cycles are super slow. There is probably some damage to a component. I seem to recall there being a resistor that gets fried pretty often.

[ben-hawks]

So, I further strengthened the idea that it is some sort of hardware issue with my specific unit. I had another unit (Still same CREX001, just the pink edition 😉 ) that I also wanted to install this on, flashed it with just
avrdude -c usbtiny -p m1281 -U flash:w:FreeExpression.hex:i (so no setting fuses or flashing the EEPROM)

and it worked like a charm, cut successfully via the latest (well, 1.0.1) with the mentioned settings and it worked beautifully!

I still would like to try and troubleshoot the slow machine, I would rather not see it become e-waste. I'm probably going to try and set the fuses to the default values first (@wildseyed if you know these, it would be super helpful!), though I doubt that's the issue. If that doesn't work, I'll move onto checking components on the board (Oscillators are the culprit I'm expecting, though I'm sure it could be anything.)

[daedalus23]

So, I further strengthened the idea that it is some sort of hardware issue with my specific unit. I had another unit (Still same CREX001, just the pink edition 😉 ) that I also wanted to install this on, flashed it with just
avrdude -c usbtiny -p m1281 -U flash:w:FreeExpression.hex:i (so no setting fuses or flashing the EEPROM)

and it worked like a charm, cut successfully via the latest (well, 1.0.1) with the mentioned settings and it worked beautifully!

I still would like to try and troubleshoot the slow machine, I would rather not see it become e-waste. I'm probably going to try and set the fuses to the default values first (@wildseyed if you know these, it would be super helpful!), though I doubt that's the issue. If that doesn't work, I'll move onto checking components on the board (Oscillators are the culprit I'm expecting, though I'm sure it could be anything.)

Do you have the default fuse values?

[jonpry]

Even though #18 mentions to use fuse values 0x42, 0xD9 and 0xFF. I believe this lfuse value is incorrect as that would set the system up to use the internal RC oscillator and then divide the clock by 8, yielding a frequency of 1mhz. Setting lfuse to 0xFF makes the system clock 16mhz, which matches the F_CPU configuration in the code.

However, after fixing this, I am having similar issues to the OP. If I comment out timer_init(), then the display updates near instantly. With timer_init(), the display takes almost 30 seconds to clear. As if it is spending near 100% of time in the timer interrupt. Also when the device tries to home, it shuts down after about 500mS. I think this is due to some kind of overcurrent condition. The steppers seem very loud. Perhaps the stepper update is too fast and there is shoot through in the driver?

[dolfelt]

@jonpry I was having the same issue, but burning the low fuse to 0xFF seems to speed everything up for me. But I agree that the left/right stepper is quite loud, which seems wrong.

I found this page (https://github.com/Fordi/licut/wiki/Cricut-Expressions-Hardware) and set my fuses to what it specifies there and the speed still seems fine. Unfortunately still can't get it to cut from Inkscape reliably...

[ellisgl]

The original firmware might have a PWM routine to quiet it down.