I just installed 4.1 on my FOCBOX. It took about 2 hours. That’s not exactly what I would call fast. I was actually surprised it didn’t fail. Anyone else having the issue or is it just me?
4 Likes
Firmware flash took 2 hours? ;O
Do you have another to roll the dice on to see if that’s reproducible?
4 Likes
I would have hard rebooted it thinking it was stuck long, long, long before 2 hours elapsed.
5 Likes
What FW did you have installed earlier?
Jumping from Ack 3.103 to 4.1 takes that long, even for me.
If you jump from Ack 3.103 to 3.66 for example it takes seconds and then from 3.66 to 4.1 it also takes just seconds like it should. But 3.103 to 4.1 takes literally hours.
17 Likes
That must be it. Thanks.
Anyone knows the reason for this?
4 Likes
Probably those pesky groundloops. I jest.
I would imagine the bootloader is not the same between 3.103 and 4.0+, but as to why it takes hours as opposed to failing or timing out… No idea. Got an Stlink v2 and/or buspirate?
1 Like
Now I know nothing of code but may be, just may be, it’s like wanking. Doing it twice in a row is hard but if you do twice at different times of the day or in two separate intervals it’s easy.
I could be wrong though so please excuse my inexperience.
9 Likes
I do. According to what @xsynatic wrote though, it doesn’t seem to have to do with 4.x FW but is rather related to switching from Ack fw to the standard fw in general.
1 Like
Just wondering if there is any effect on the regen when using HFI?
2 Likes
I believe this is most likely due to memory access operations. Now I don’t know exactly how the flashing routine works for this specific case, but I assume it has to do with sequential vs random read/write operations.
Seeing how large are the changes in c code between Ack fw and 4.x fw, the resulting compiled binary is going to occupy a fairly different memory block addresses. With this in mind, if updating to a contiguous firmware for example, the chances that most of the compiled binary data are going to remain unchanged are high, meaning only a small portion would need to be updated on the memory, this happens relatively quick because the flashing routine reads those blocks first and knows that they are unchanged, thus skipping the expensive write operations.
When a lot has changed code wise, flashing would technically take a longer time to override all the changed blocks, and this depends on how contiguous those block are to each other, how many random read/write vs sequential read/write are there, the page size, and actual written data size.
But of course those are all assumptions, and I’m pretty sure some other factors are weighing in as well.
6 Likes
I assumed it had something to do with firmware compression or something like that that was implemented at some point.
1 Like
7 Likes
It’s definitely firmware compression.
5 Likes
Keep getting this error when trying to setup my motors in fox with 2x VESC6
Tried resetting the firmware but didn’t help please could someone give me a fix as would love to be riding again tomorrow
Small update review…
Idk what firmware the issue started or if its in all of them
Just a psa since it seems I’m not the only person with this issue.
I get firmware induced speed wobbles. Always at the exact same speed. (Focbox in Foc)
…Went back to Ackmaniac “Speed wobbles” are gone.
Also got cutout under hard acceleration (Not 100% sure if this is firmware issue)
wh/mi calculation is incorrect as far as i can tell (measured against powerlab 6)
6 Likes
The speed wobbles, are they like a rubberband pulling you back a bit, over and over?
I guess that’s one way of putting it… I forgot to mention here is that it is audible, i can hear the motor “switching” I assume back and forth… Always at 31mph for me. That’s approximately 80% duty cycle on my setup
3 Likes
Are you using a metr pro with TPC bridge?
I had the same kind of issue with my vesc 3.62. I just redid it multiple times and it somehow worked out for me.
1 Like