Toyota GR86, 86, FR-S and Subaru BRZ Forum & Owners Community - FT86CLUB

- Issues | Warranty | Recalls / TSB (https://www.ft86club.com/forums/forumdisplay.php?f=72)

- - Toyota's killer firmware (https://www.ft86club.com/forums/showthread.php?t=50251)

Toyota's killer firmware

Pretty technical, but proof that so many car issues today come from bad software:

http://www.edn.com/design/automotive...s-consequences

Quote:

Stack overflow. Toyota claimed only 41% of the allocated stack space was being used. Barr's investigation showed that 94% was closer to the truth. On top of that, stack-killing, MISRA-C rule-violating recursion was found in the code, and the CPU doesn't incorporate memory protection to guard against stack overflow.

Quote:

A litany of other faults were found in the code, including buffer overflow, unsafe casting, and race conditions between tasks.

I would have expected better from Toyota.

And as a programmer, I find this embarrasing. :thumbdown:

Reeks of expert testimony using a shotgun approach -- i.e. a bunch of "could-be"s versus a definite "this is what caused the issue".

Don't get me wrong, I have no doubt there are bugs -- programmers are far from perfect and even the best, most careful of practices lead to some bugs happening. Coding is hard :)

The correlative of this is that understanding someone else's code is hard -- I can look at someone's code and list off a ton of "could-be"s, when they've already taken care of the corner cases in some way that I'd only realize upon a deeper analysis.

Quote:

Originally Posted by R.S-HawK (Post 1301223)

And as a programmer, I find this embarrasing. :thumbdown:

The article was clearly not written by a programmer. I'd be curious to see the original technical document. This contains some very WTF wording that doesn't mean anything to a programmer:

Quote:

Toyota missed some of the calls made via pointer, missed stack usage by library and assembly functions (about 350 in total), and missed RTOS use during task switching.

It lists a number of things which are not bugs, but merely describe a lack of safety nets to catch certain very specific types of bugs:

Quote:

Toyota claimed the 2005 Camry's main CPU had error detecting and correcting (EDAC) RAM. It didn't.

...

Mirroring (where key data is written to redundant variables) was not always done.

...

Stack overflow. Toyota claimed only 41% of the allocated stack space was being used. Barr's investigation showed that 94% was closer to the truth. On top of that, stack-killing, MISRA-C rule-violating recursion was found

And some things here which could be bugs but the rest of the article leads me to think they just mean a potential for bugs -- this kind of code has been deemed attention-worthy by the software industry due to being difficult to get right and being the most common areas to find bugs:

Quote:

A litany of other faults were found in the code, including buffer overflow, unsafe casting, and race conditions between tasks.

time for an aftermarket tune! :thumbsup:

Quote:

Originally Posted by suaveflooder (Post 1302003)

time for an aftermarket tune! :thumbsup:

No. A tune does not touch any of this.

Quote:

Originally Posted by phrosty (Post 1301998)

The correlative of this is that understanding someone else's code is hard -- I can look at someone's code and list off a ton of "could-be"s, when they've already taken care of the corner cases in some way that I'd only realize upon a deeper analysis.

Sounds like you are describing an inefficient programmer, partially what the article is saying.

Quote:

Originally Posted by suaveflooder (Post 1302003)

time for an aftermarket tune! :thumbsup:

http://jaclpetersen.files.wordpress....pg?w=286&h=300

Quote:

Originally Posted by ft_sjo (Post 1302190)

No. A tune does not touch any of this.

http://s.pikabu.ru/images/big_size_c...5988769617.jpg

Quote:

Originally Posted by ft_sjo (Post 1302190)

No. A tune does not touch any of this.

Exactly. My understanding is that all a tune does is change a bunch of constants (the spreadsheets/data tables of tuning parameters) that the ECU code passes into its functions to Do Things. (Is function the right term here? I come from the land of objects, I dunno about this low-level stuff.)

A tune has nothing to do with said functions nor can it change their implementation.

Quote:

Originally Posted by PantsDants (Post 1302295)

The flash (or multiples of) will contain program areas and data areas. Tuning typically affects the latter, however people like EcuTek bastardise the program area for their 'RaceROM' thing. It can lead to instability issues though, which was exhibited on our cars with the fuel gauge playing up, for example. I believe they pulled that code/hack now.

For a long time now Toyota has been ruled by Committee not Passion ! They still have an enviable reputation for design & build quality but it has been slipping . . . . unfortunately :/

everytime i read "unintended acceleration" on the internet, i always think of this:
http://www.nasa.gov/topics/nasalife/...ota-study.html

Quote:

Originally Posted by fistpoint (Post 1302270)

Sounds like you are describing an inefficient programmer

Indeed. In my experience, programmers who don't write straightforward code outnumber the ones who do. :sigh:

Quote:

Originally Posted by suaveflooder (Post 1302003)

time for an aftermarket tune! :thumbsup:

"Firmware" means hardware. You may be able to flash a new version of the firmware, but if the hardware itself is busticated there's not much you can do.

If I were Toyota, I'd be having a lawyer make a phone call about this headline:
Toyota's killer firmware: Bad design and its consequences