How to downgrade to previous float package?

Hi all,

Since updating to float package 2.0, on my Focer 3.1, I’ve gotten weird issues with my headlights that are run by an arduino. The arduino is using the vescUart library, and will run the headlights normally for a few seconds before freezing. If I go to “app config” and change “app to use” to None, then change it back to UART, it sometimes fixes the issue, but power cycling the board causes the arduino to freeze again. (Normally the headlights will react to motor rpm)

I’m not sure changing app config actually does anything since “enable permanent UART” must be set to true. I learned that the hard way after loosing Bluetooth access.

This issue popped up after I installed the new float package, so I’m curious if there’s a way to downgrade to 1.3 to test if it’s truly a bug vs a poorly timed arduino issue.

Any help appreciated. Thanks!

That might be because the new LED code is quite impolitely and unconditionally deinitializing the timer/DMA used for the LEDS on the new VESCs, without a consideration those might be used for something else on other hardware.

@surfdado @NuRxG

1 Like

Oh, and I just realized, you don’t have the previous version of the package to downgrade to, right? I expected to find it among releases on @surfdado’s github repo, but there are none.

I wanted to attach a package for you, but the forum doesn’t allow it. @surfdado should be able to sort you out eventually…

1 Like

Thanks for the reply! The timer issue makes a lot of sense. Would you have any idea how to resolve that with code on the arduino side?

Also, I did a bit more digging and have some more accurate more details:

-If I start up my vesc with app config as “No App” and then switch it to “UART” after it has powered on, the arduino reacts normally.

-On the other hand, if I power the board on with UART enabled from the start, after a short while, it causes my arduino to flash the “MBed OS crashed” sequence (4 short and then 4 long blinks of the red LED). This always seems to happen right when the motor engages, so my first guess was that electrical interference is corrupting the first few data packets on startup.

Hopefully this extra info is helpful! I’ll try to see if I can get a crash report from the arduino eventually, but right now it’s buried in my board haha.

Oh and you are correct, I don’t have the previous package. I’ve also tried to find the older float package on GitHub, but was unsuccessful.

The bug is in Float package 2.0. It matches exactly with what you describe. When Float loads up (pretty much exactly at the time the motor engages), it deinitializes the timer and DMA as part of the LEDs initialization sequence (this is wrong, it can’t be done that way, especially when you don’t even have the LEDs enabled in the first place). At that time, the UART stops working for your Arduino (looks like it’s not handled gracefully on Arduino side if you get the crash).

If, after Float started, you change the configuration of the UART, VESC will re-initialize it properly and it’ll start working (until you restart Float…).

If you need to get it working, I’ve uploaded a build of the Float package from @surfdado’s github main branch here:

It’s basically 1.3 with some minor fixes and AFAIK one bug introduced: Flywheel doesn’t turn off by pressing sensors when it’s not running (this one is on me :sweat_smile:). So just don’t use Flywheel or be aware.

But, I expect it’ll get fixed in Float pretty quick once the guys notice the mentions…

Sweet, this makes a lot more sense now. And thanks for the link!

I’ve let Mitch know about this

1 Like

Latest v2.0b should have this fixed. Please try it out

Hmm despite setting LEDs to None in float config, the behavior is still the same.

I also tried the older float package today and it works as expected with v1.3.

Can you double-check? I’ve had a look at the fix and it should definitely do the job. And I can’t think of anything else in there could cause this… Maybe you forgot to refresh the package archive or something?

The changes do make sense, exiting the function when LEDs none is selected…

But alas, just did a quick confirmation today. Downloaded the 2/17/2024 dated float

  • it froze after the install, which I think is expected.

  • It worked on after the first power cycle, but froze again when I tried to test it further.

I made sure to set my LEDs to None… it’s possible that my arduino code could be shit?

Erm… I abstain from judging :grin: Did you write the code? I’d say you can try to debug it, have a look at how it interacts with the VESC etc.

But that’s probably going to be hard and if it has worked before, it should work now as well. If you’re able, you can try to compile the Float package, that’s not too hard if you can program an Arduino, you just need GCC ARM compiler, make and vesc_tool (on Linux or WSL for Windows).

Then just run make or make VESC_TOOL=/path/to/vesc_tool in the float directory (you may hit Calling vesc_tool from the Makefiles fails on some systems · Issue #33 · vedderb/vesc_pkg · GitHub).

If you manage to compile it, you can try to hack the code - comment out the LED functions or bisect git history to see what commit broke your use case.

Yep, I wrote a good chunk of the code myself, aside from some of the wifi parts.

Thanks for the info on how to compile float package! I’ve been meaning to ask how to do that and it’ll be cool to play around with editing/adding functions.

I’ll try to set aside some time for seeing what makes my arduino unhappy. Will report back if I identify it :saluting_face:

1 Like

So I switched to an arduino nano esp, and the problem doesn’t seem to exist on that board, instead of freezing when float initializes, it reboots and works properly, so freezing is something specific to the RP2040 but I haven’t had time to look into exactly why that is.

In either case the problem is resolved on my end.

Unrelated, I got OTA updates working on the ESP version too!