Autosport Labs

After update completion from 2.8.6 to 2.8.7 I get a continual "Connecting" "Connected" "RaceCapture 2.8.7" status cycle. A quick flashing yellow light followed by a slow blinking red light when it goes back to "Searching". Occasionally a message of "0.0.0.0, You need at least 2.8.x firmware" or "Unable to read configuration" is shown.

I confirmed 2.8.6 works properly by downgrading to it. I upgraded back to 2.8.6 and the connectivity issues return. I'm now back to 2.8.6 again and everything is stable once more, with a quick flashing yellow light.

Can I get a response, please? I'm at a standstill with my 29-bit development because 2.8.6 doesn't support it and 2.8.7 will not properly run and connect.

2.8.6 firmware updates work correctly with 1.4.1 and 1.4.2. 2.8.7 does not stay connected and always has a slow blinking red light.

Hey imstimpy,

Sorry for the delay on the response. Interesting issue. Sounds like a watchdog (hard lockup prevention) but not sure of the cause at the moment. When you see the blinking red light, try clicking the logging button. The blinking red light is a way to disable the LUA runtime so the unit can boot. Its possible you are encountering a crash bug somewhere in the LUA runtime or some place else. Anyway... let start there and see what happens.

Also if we are slow on a response in the forums, please do ping us on our FB page and we'll come help you out. Gotta upgrade these things. Cheers.

I cleared my LUA script then upgraded to 2.8.7 and that worked.

I pasted my LUA script and it immediately disconnected with the slow blinking red light.

Pressing the datalog button appears to stop the slow blinking red light on 2.8.7.

It is entirely possible there is something bad in my LUA script, but the script does work on 2.8.6.

At the moment, I don't have the time to iterate over the script and find the issue. I can, it may just take a day or two.

So loaded up your script and immediately hit the same issue. I have the debugger on and am working on it locally. Will let you know if I find anything.

Well... I have to admit that the root cause has got me stumped. But I do have a workaround that solves the problems. So hooray!

The crash is caused by line 110 in the `processISO` method. Simply commenting out this line gets us past the crash issue and things work again. I tried this script on 2.8.7, 2.8.6 and 2.8.5 and saw the crashing behavior on all versions... so this isn't a new bug. What I don't understand is why this is happening. That code isn't being invoked at all, so the fact that LUA still dies outright befuddles me.

Looking at the code there is a flaw in the design. LUA is fairly particular about how one defines keys in an array. Its possible that because you use key values '0x01' etc for the index in ISOCAN_map, it won't match up to the value i = 1. This is because LUA may represent 1 as a floating or double precision value under the hood. You can read more about it here: http://www.lua.org/pil/2.5.html

Anyway... to achieve the intended behavior I updated the method and made use of the `ipairs` operator. That operator allows you to easily iterate a table, thus getting your desired behavior. I tested this with the runtime and it is stable. So enjoy.

And here is what more debugging found: https://github.com/autosportlabs/RaceCa ... issues/411

Good find.

Thanks for the research, explanation, and alternate code. I apologize for invoking a crash through my prototype code. Because 29-bit was not working on 2.8.6, txCAN never returned 1 and I could not iterate on the response. I'll upgrade to 2.8.7 and continue investigating 29-bit packet handling.

I am quite surprised that commented-out code can break the runtime in 2.8.7 but not on 2.8.6.

I apologize for invoking a crash through my prototype code.

HA! Not your fault. Not like you are trying to crash it or anything .

I am quite surprised that commented-out code can break the runtime in 2.8.7 but not on 2.8.6.

Are you sure its the exact same code as on 2.8.6? I downgraded my RCP to 2.8.6 and hit the crash. Even on 2.8.5. That is what lead me to figure out it wasn't a regression in 2.8.7. Its possible that you may have gotten lucky and that a race condition in the firmware prevented this issue from happening. Hardware can be tricky from time to time.

Glad we got it solved.