I'm currently looking at replacing the processor in a safety critical system from an 80188 to likely some form of ARM. I'd been told that this might be tricky because approvals houses (mainly TUV and GasTec) like to step through the code on an in-circuit emulator rather than stepping through code on a JTAG emulator. This seems unlikely to me but could it be true? Surely the JTAG method is used a lot these days.
Safety Critical ARM
Started by ●March 2, 2007
Reply by ●March 2, 20072007-03-02
"Tom Lucas" <news@REMOVE_auto_THIS_flame_TO_REPLY.clara.co.uk> wrote in message news:1172855473.15269.0@proxy02.news.clara.net...> I'm currently looking at replacing the processor in a safety critical > system from an 80188 to likely some form of ARM. > > I'd been told that this might be tricky because approvals houses (mainly > TUV and GasTec) like to step through the code on an in-circuit emulator > rather than stepping through code on a JTAG emulator. This seems unlikely > to me but could it be true? Surely the JTAG method is used a lot these > days. >SafeRTOS (see link in sig) - ARM7 with JTAG for IEC 61508 SIL 3 no problem. You don't say which standard you are using though. The *essential* thing is to get agreement on your approach prior to starting the project so if you can formulate an argument for JTAG and get it accepted up front then you 'should' be ok. I have seen it stated that going above a certain SIL levels requires an in-circuit emulator, but this was in documentation provided by a company that sells in-circuit emulators. You need to check the standard to which you are working. Even if its in the standard, and you are not conforming, you can probably formulate a decent argument for a deviation. For example, from memory IEC 61508 'highly recommends' a strongly typed language [I would have to double check the actual wording] - but SafeRTOS is written in C. We got this agreed up front and it was not mentioned again until the final audit, at which time the appropriate box was ticked. -- Regards, Richard. + http://www.FreeRTOS.org A free real time kernel for 8, 16 and 32bit systems. + http://www.SafeRTOS.com An IEC 61508 compliant real time kernel for safety related systems.
Reply by ●March 2, 20072007-03-02
FreeRTOS.org wrote:> "Tom Lucas" <news@REMOVE_auto_THIS_flame_TO_REPLY.clara.co.uk> wrote in > message news:1172855473.15269.0@proxy02.news.clara.net... >> I'm currently looking at replacing the processor in a safety critical >> system from an 80188 to likely some form of ARM. >> >> I'd been told that this might be tricky because approvals houses (mainly >> TUV and GasTec) like to step through the code on an in-circuit emulator >> rather than stepping through code on a JTAG emulator. This seems unlikely >> to me but could it be true? Surely the JTAG method is used a lot these >> days. >> > > SafeRTOS (see link in sig) - ARM7 with JTAG for IEC 61508 SIL 3 no > problem. > You don't say which standard you are using though. The *essential* thing > is to get agreement on your approach prior to starting the project so if > you can formulate an argument for JTAG and get it accepted up front then > you 'should' be ok. > > I have seen it stated that going above a certain SIL levels requires an > in-circuit emulator, but this was in documentation provided by a company > that sells in-circuit emulators. You need to check the standard to which > you are working. Even if its in the standard, and you are not conforming, > you can probably formulate a decent argument for a deviation. For > example, from memory IEC 61508 'highly recommends' a strongly typed > language [I would > have to double check the actual wording] - but SafeRTOS is written in C. > We got this agreed up front and it was not mentioned again until the final > audit, at which time the appropriate box was ticked.You could use a safer subset of any language. C coding to the MISRA-C rules would be looked upon favourably. That said, the planning out of how you are going to prove you will meet the Essential Safety Requirements for a system is an important first step and this is where some effort should be expended. This may need you to do a HAZOP study or some other form of Hazard Identification and Mitigation durng the devlopment phase. As you are updating on a processor, ou should have a reasonable idea of what Hazards your system will meet. It will, however, be worthwhile doing a full review just to make sure that the Safety Analysis is current. Although IEC61508 recommends a strongly typed language you can argue that, due to the attention to detail in other areas of software construction, you may not need to be so reliant on strong typing. -- ******************************************************************** Paul E. Bennett ....................<email://peb@amleth.demon.co.uk> Forth based HIDECS Consultancy .....<http://www.amleth.demon.co.uk/> Mob: +44 (0)7811-639972 Tel: +44 (0)1235-811095 Going Forth Safely ..... EBA. www.electric-boat-association.org.uk.. ********************************************************************
Reply by ●March 2, 20072007-03-02
Tom Lucas <news@remove_auto_this_flame_to_reply.clara.co.uk> wrote:> unlikely to me but could it be true? Surely the JTAG method is used a > lot these days.I know of a customer who has a control system running on ARM for which the requirement was that the kernel must run from reset with linear code with no branches in it. The processor was then reset and it did it again etc. The validation for this was based on a historical instruction trace obtained via the Embedded Trace Macrocell of the entire execution of the program. Stepping through with a real ICE is nonsense from the safety citical validation point of view because the real processor will have different timing behaviour and crucially different errata from the ICE implementation. Obviously I can't name the customer but lets just say large objects would fall out of the sky if the system failed. -p -- "Unix is user friendly, it's just picky about who its friends are." - Anonymous --------------------------------------------------------------------
Reply by ●March 3, 20072007-03-03
In article <-nf*XxIEr@news.chiark.greenend.org.uk>, Paul Gotch <paulg@at-cantab-dot.net> writes>Stepping through with a real ICE is nonsense from the safety citical >validation point of view because the real processor will have different >timing behaviour and crucially different errata from the ICE implementation.This is incorrect. It depends on the MCU and the ICe -- \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\ \/\/\/\/\ Chris Hills Staffs England /\/\/\/\/ /\/\/ chris@phaedsys.org www.phaedsys.org \/\/\ \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/
Reply by ●March 3, 20072007-03-03
Chris Hills <chris@phaedsys.org> wrote:> This is incorrect. It depends on the MCU and the ICeSo you are saying that in most cases it is correct then? Which MCUs are you claiming that an ICE version can be proved to be exactly equivalent to the real processor and how is this proof done? In this case it's academic since I know of no traditional ICEs that emulate a ARMs they'd need an architecture license in order to do so. -p -- "Unix is user friendly, it's just picky about who its friends are." - Anonymous --------------------------------------------------------------------
Reply by ●March 4, 20072007-03-04
On Mar 3, 4:10 pm, Paul Gotch <p...@at-cantab-dot.net> wrote:> Chris Hills <c...@phaedsys.org> wrote: > > This is incorrect. It depends on the MCU and the ICe > > So you are saying that in most cases it is correct then? Which MCUs are you > claiming that an ICE version can be proved to be exactly equivalent to the > real processor and how is this proof done? > > In this case it's academic since I know of no traditional ICEs that emulate > a ARMs they'd need an architecture license in order to do so. > > -p > -- > "Unix is user friendly, it's just picky about who its friends are." > - Anonymous > --------------------------------------------------------------------The bondout chip was usually identical in timing and Erratas at the time it hit the market but it was not feasible to update the bondout chip every time the production chip was fixed. So, over time they drifted apart until a bondout redesign was done. The good news is that with an ARM that includes ETM, the above mentioned obsticles are not present any more. The production chip has the emulation build in. Advantage, real-time execution trace is possible, disadvantage, you will loose some pins. The ETM got different priorities from different manufacturers of ARM devices. Most ARM7 devices do not include ETM, many ARM9 devices do. Exception on ARM7 is NXP which delivers most devices with ETM. Robert
Reply by ●March 5, 20072007-03-05
In article <eyd*KoOEr@news.chiark.greenend.org.uk>, Paul Gotch <paulg@at-cantab-dot.net> writes>Chris Hills <chris@phaedsys.org> wrote: >> This is incorrect. It depends on the MCU and the ICe > >So you are saying that in most cases it is correct then? Which MCUs are you >claiming that an ICE version can be proved to be exactly equivalent to the >real processor and how is this proof done?There are quite a few ICE with exact emulation. I know of one lot that were used on a Satellite if they did some independent tests to verify this before using the ICE. I have seen similar things done for smart cards. In some cases where the busses are visible the same part is used in the ICE as production. So the emulation is 100% accurate In some cases the bond out part is the same as the production silicon it is just a different package. However there are times when the bond out and the target are not exactly the same. Of course for some single chip parts the same MCU is used in both the Ice and production eg for the 8051 using Hoooks (basic or enhanced)>In this case it's academic since I know of no traditional ICEs that emulate >a ARMs they'd need an architecture license in order to do so.This is true. It is not just a core license you will need to be able to do the peripherals as well. -- \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\ \/\/\/\/\ Chris Hills Staffs England /\/\/\/\/ /\/\/ chris@phaedsys.org www.phaedsys.org \/\/\ \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/
Reply by ●March 5, 20072007-03-05
In article <1173037058.700819.31000@8g2000cwh.googlegroups.com>, Robert.NXP@gmail.com writes>On Mar 3, 4:10 pm, Paul Gotch <p...@at-cantab-dot.net> wrote: >> Chris Hills <c...@phaedsys.org> wrote: >> > This is incorrect. It depends on the MCU and the ICe >> >> So you are saying that in most cases it is correct then? Which MCUs are you >> claiming that an ICE version can be proved to be exactly equivalent to the >> real processor and how is this proof done? >> >> In this case it's academic since I know of no traditional ICEs that emulate >> a ARMs they'd need an architecture license in order to do so. >> >> -p >> -- >> "Unix is user friendly, it's just picky about who its friends are." >> - Anonymous >> -------------------------------------------------------------------- > > >The bondout chip was usually identical in timing and Erratas at the >time it hit the market but it was not feasible to update the bondout >chip every time the production chip was fixed. So, over time they >drifted apart until a bondout redesign was done. >The good news is that with an ARM that includes ETM, the above >mentioned obsticles are not present any more. The production chip has >the emulation build in. Advantage, real-time execution trace is >possible, disadvantage, you will loose some pins. >The ETM got different priorities from different manufacturers of ARM >devices. Most ARM7 devices do not include ETM, many ARM9 devices do. >Exception on ARM7 is NXP which delivers most devices with ETM. > >Robert >Hi Robert. (Robert T I assume) Not only were many of the bond out parts identical (bar the different package with more pins) some did not need a bond out as the busses were visible externally anyway. Also there was, for the 8051 the hooks system, which meant the same part was used in the ICE as the target. I am still not convinced the that JTAG/ETM is as good as a full ICE but in time I think there will be a one or two wire debug system that will be used generally on most parts that will be as good as the old full ICE. Regards Chris PS have you see the new Embedded Internet book? You should have had some on the stand at Nuremberg -- \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\ \/\/\/\/\ Chris Hills Staffs England /\/\/\/\/ /\/\/ chris@phaedsys.org www.phaedsys.org \/\/\ \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/
Reply by ●March 5, 20072007-03-05
"Paul E. Bennett" <peb@amleth.demon.co.uk> wrote in message news:esa1tc$nbt$1$8302bc10@news.demon.co.uk...> FreeRTOS.org wrote: > >> "Tom Lucas" <news@REMOVE_auto_THIS_flame_TO_REPLY.clara.co.uk> wrote >> in >> message news:1172855473.15269.0@proxy02.news.clara.net... >>> I'm currently looking at replacing the processor in a safety >>> critical >>> system from an 80188 to likely some form of ARM. >>> >>> I'd been told that this might be tricky because approvals houses >>> (mainly >>> TUV and GasTec) like to step through the code on an in-circuit >>> emulator >>> rather than stepping through code on a JTAG emulator. This seems >>> unlikely >>> to me but could it be true? Surely the JTAG method is used a lot >>> these >>> days. >>> >> >> SafeRTOS (see link in sig) - ARM7 with JTAG for IEC 61508 SIL 3 no >> problem. >> You don't say which standard you are using though. The *essential* >> thing >> is to get agreement on your approach prior to starting the project so >> if >> you can formulate an argument for JTAG and get it accepted up front >> then >> you 'should' be ok. >> >> I have seen it stated that going above a certain SIL levels requires >> an >> in-circuit emulator, but this was in documentation provided by a >> company >> that sells in-circuit emulators. You need to check the standard to >> which >> you are working. Even if its in the standard, and you are not >> conforming, >> you can probably formulate a decent argument for a deviation. For >> example, from memory IEC 61508 'highly recommends' a strongly typed >> language [I would >> have to double check the actual wording] - but SafeRTOS is written in >> C. >> We got this agreed up front and it was not mentioned again until the >> final >> audit, at which time the appropriate box was ticked. > > You could use a safer subset of any language. C coding to the MISRA-C > rules > would be looked upon favourably. That said, the planning out of how > you are > going to prove you will meet the Essential Safety Requirements for a > system > is an important first step and this is where some effort should be > expended. This may need you to do a HAZOP study or some other form of > Hazard Identification and Mitigation durng the devlopment phase. As > you are > updating on a processor, ou should have a reasonable idea of what > Hazards > your system will meet. It will, however, be worthwhile doing a full > review > just to make sure that the Safety Analysis is current. > > Although IEC61508 recommends a strongly typed language you can argue > that, > due to the attention to detail in other areas of software > construction, you > may not need to be so reliant on strong typing.My language selection is fine at the moment - the system is mature and the code is written and the approvals bodies are all happy with it. I plan to talk to them before embarking on a processor change but I just wanted to ask if there were an obvious gotchas before I went into the meeting.