When I worked at Ericsson, we needed a small embedded Rtos, so it was developed in-house and used in their line of DECT phones and base stations. I got intimately familiar with it, because one of the first things I got to do as a new hire was to trouble-shoot a new proposed release of an existing product, which showed unexpected reboots. Since it was a minimal Rtos, it did not have much in the way of error checking and I added/enabled several optional safeguards such as writing and checking a magic number at the end of the stack space. Other faults were more difficult to find, such as writing an error log using a pointer into the array of error msg structures. Unfortunately someone forgot to initialize the index into the array and the usual RAM value on power up is a negative number. Oops. After finding this and similar errors and fixing them, the software started running without crashing. I made sure that the next platform (which I helped develop from the start) retained and improved on error checking and C code analysis and review. I enjoy still finding base stations in operation in some professional locations such as factories, hotels and airports 15 years later.
Cor van de Water Chief Scientist Proxim Wireless Corporation http://www.proxim.com Email: [email protected] Private: http://www.cvandewater.info Skype: cor_van_de_water Tel: +1 408 383 7626 -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Michael K Johnson Sent: Wednesday, January 15, 2014 7:09 PM To: Electric Vehicle Discussion List Subject: Re: [EVDL] RE, zoom zoom On Wed, Jan 15, 2014 at 8:24 PM, Chris Tromley <[email protected]> wrote: > What kind of validation protocols do you think the automakers are > subjecting their code to? And what regulatory body approves it? Remember > the BMW luxo-barge that had to be recalled because the entry/security > software would occasionally lock occupants INSIDE the car? That's right, > once you were in you couldn't get out without breaking a window or calling > a cop or locksmith. Supporting your point from the perspective of another automaker, I found the following article interesting a few months ago: http://www.edn.com/design/automotive/4423428/Toyota-s-killer-firmware--B ad-design-and-its-consequences ... 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. ... Although Toyota had performed a stack analysis, Barr concluded the automaker had completely botched it. 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. They also failed to perform run-time stack monitoring. ... A litany of other faults were found in the code, including buffer overflow, unsafe casting, and race conditions between tasks. _______________________________________________ UNSUBSCRIBE: http://www.evdl.org/help/index.html#usub http://lists.evdl.org/listinfo.cgi/ev-evdl.org For EV drag racing discussion, please use NEDRA (http://groups.yahoo.com/group/NEDRA) _______________________________________________ UNSUBSCRIBE: http://www.evdl.org/help/index.html#usub http://lists.evdl.org/listinfo.cgi/ev-evdl.org For EV drag racing discussion, please use NEDRA (http://groups.yahoo.com/group/NEDRA)
