News

Have you covered *this* when testing C and C++ Software?

The ability to produce reliable technologies that rapidly follow market trends creates a competitive advantage in the digital world.     Part of being a technology company is about producing reliable technology at a rapid pace. At the same time, we cannot sacrifice code quality just to deliver slightly faster. One of the primary tools for ensuring code quality while maintaining a rapid release schedule is writing good tests. Like any other skill, test writing is best developed through practice and experience. Monitoring development performance and knowing when you have tested enough are very valuable things to consider in any software development project.   Many software developers are surprised when the customer reports an error. We spend countless hours defining requirements, testing code and reviewing the final product. Despite this time investment how is it that mistakes find their way into the deliverable unnoticed?   Assuming that the customer is reporting valid concerns, we can answer the question with one of the following statements:   > The customer has executed part of the application that has never been tested. Incomplete testing could be deliberate due to time or cost constraints.   > The order or process in which a customer has used the software is different from the use anticipated by the development team or, more likely, the testing team. This actual usage was not built into the test suite.   > A combination of inputs were received by the application that were never tested. Software is rarely tested with every possible input value. It is the job of the tester to select a reduced set of typical input conditions that reproduce real-world usage. If the assumptions of the tester are wrong, errors slip through.   > The environment in which the software is being used differs between the develop/test teams and the customer. Typical discrepancies can be a different operating system version or hardware. Perhaps the real-world environment was not available to the test team at all, and it had to be simulated or assumed.   Just Test It Software is almost never 100% tested. Unfortunately, this even applies to the more rigorously tested safety-critical embedded applications.     Consider a piece of control software which processes up to 30 different input variables. If we wanted to test all possible input combinations and prove that there were no unwanted interrelations between the inputs, we would have to test for 20 years, even if we could create and run 100 test cases per second.   Various measurements of coverage can be used to set and monitor testing progress and performance to help minimise the occurrence of errors in the field.   Consider a piece of control software which processes up to 30 different input variables.   If we wanted to test all possible input combinations and prove that there were no unwanted interrelations between the inputs, we would have to test for 20 years, even if we could create and run 100 test cases per second.   Various measurements of coverage can be used to set and monitor testing progress and performance to help minimise the occurrence of errors in the field.   Coverage Concepts   Throughout the software industry, many commonly used terms have no concrete definition. The meaning of technical terms fluctuates depending on who you are talking to. Software testing is an essential activity in the software development and maintenance life cycles. It is a practice often used to decide and improve software quality. When it comes to measuring software testing performance and progress, it is therefore essential that everyone has the same understanding of the measurement terms (metrics) used.   ‘Coverage’ is a broad umbrella term that encompasses a number of useful numerical measures for developers of robust software systems. These measures, when used effectively, can be used both to define quality goals for your end product and track your progress towards achieving them.   In software testing, there are 3 basic types of items to which coverage measurements can be applied:   > Requirements — various levels of detail defining e.g. functional, safety or non-functional (such as performance or usability) what the software should do, and sometimes what it should not do.   > Code — implementation in software (and sometimes hardware or firmware) to meet the requirements.   Tests — a means to verify that the software does what it should do (and sometimes what it should not do — often called robustness tests).   The 3 different uses of the term ‘coverage’ should not be confused. Requirements coverage measures the proportion of requirements which have been verified by requirements-based tests. Structural Code coverage measures the proportion of the code which has been executed by tests. Test coverage measures the proportion of tests which have been run and passed.   Working to standards   If you are working in a safety-critical industry, it is likely that you will be working toward achieving certification in the relevant international software standard. The standard and integrity level within it that you are working towards, will determine the coverage metrics and target coverage values that you should achieve in your project.   Safety-critical software standards, such as DO-178C and ISO 26262, recommend the use of requirements coverage, structural code coverage and test coverage. Correct use of these concepts can also help developers outside of the safety-critical arena. Appreciation of the terms and their use will help deliver a more reliable and robust application.     Link to Requirements   Well-defined requirements at the start of the project, or at the start of an agile sprint, will make the technical teams’ jobs easier and more measurable. It is unlikely that requirements supplied by the customer will be complete enough to ensure project success. Usually, there will be some degree of interpretation, and an upfront process of adding detail to initial high-level requirements, to help shape the architectural design and implementation of the requirements in code. Situations where requirements are not documented, or where initial requirements are not final, will mandate additional study phases with the team and agreement with the customer.   Monitor Code Coverage   Measurement of structural coverage of code is an objective means of assessing the thoroughness of testing. There are various industry-standard metrics available for measuring structural coverage, these can be gathered easily with support from software tools. Such metrics do not constitute testing techniques, but a measure of the effectiveness of testing techniques.   Different code coverage metrics measure the execution of different syntax constructs within the code. The most common code coverage metrics are:   > Function / Method Entry Points   > Function / Method Calls (and their Returns)   > Lines (of executable code)   > Statements   > Basic Blocks (of sequential Statements)   > Decisions   > Conditions (Boolean operands)   > Relational Operators   > Loops   > MC/DC (Modified Condition / Decision Coverage), both Masking & Unique Cause forms   The fundamental strategic question of how much testing you should do is generally driven by available resources, both time and budget.   Dynamic Test Results   Test coverage measures the proportion of your tests have run successfully (i.e. been executed and pass) on the code. While having tests which verify the requirements can be measured using requirements coverage, and the amount of the code executed by the test can be measured using structural code coverage, whether or not these tests are actually run and pass is the third critical thing to measure for software testing. Requirements coverage and code coverage only have meaning when the status of the tests which those metrics measure is itself measured.     Set Some Goals   Setting project goals around defined metrics, such as coverage, has several benefits to project success.   > Optimise the use of resources   There are never enough resources to do everything, so setting coverage goals can help you to prioritise. By allocating most time and budget to test what is most important you can help focus testing efforts. If you want to better manage your time on testing, a simple solution is to stop doing what doesn’t need to be done.   > Add clarity to project meetings   Knowing what you are trying to achieve means that you can tackle the question: “does this activity get me closer to my goal?” Setting goals enables you to clarify with other developers and testers what you are trying to do, and therefore what they need to do to contribute or support.   > Easier measurement of project status   Setting coverage goals allows you to measure how effectively you are moving towards completion.   An important consideration is knowing when to stop testing. For those working towards standards, the coverage goals will be mandated. For others, an important first step is defining the targets of coverage to aim for.   If you reach the end of your project and have missed or not properly completed one of the three critical components of your coverage criteria, you risk delivering code that:   > Has not been verified to meet the requirements   > Has not passed all its tests   > Has not been exercised by any tests   Take away   Obtaining coverage metrics is not a final task, but rather a constant effort towards a reliable system. The easier coverage is to monitor and report, the more useful it is to development teams. Use of coverage can guide the creation of tests cases, help optimise a set of tests and provide an empirical measure of testing sufficiency. Without measuring how much of the code is tested, verification activity always risks shipping untested code. While there are some hurdles to overcome by using coverage software in an embedded or continuous integration environment, the use of suitable tools and testing framework can solve the problems in almost all instances.   © 2025 QA Systems. Published by JORAL Technologies.

The first and only formally verified C compiler for safety-critical TriCore applications

CompCert for TriCore is a formally verified optimizing C compiler. Its intended use is compiling safety-critical software and meeting the highest levels of assurance.   Can you trust your compiler?   Compilers are complicated pieces of software that implement delicate algorithms. Bugs in compilers do occur and can cause incorrect executable code to be silently generated from a correct source program. In other words, a buggy compiler can insert bugs in the programs that it compiles.   Time and again, studies have shown that many popular production compilers suffer from miscompilation issues.   As early as in 1995, the authors of the Nullstone C conformance test suite reported [integer-division] defects in twelve of twenty commercially available compilers that were evaluated.   A decade later, E. Eide and J. Regehr showed similar sloppiness in C compilers, this time concerning volatile memory accesses: We tested thirteen production-quality C compilers and, for each, found situations in which the compiler generated incorrect code for accessing volatile variables. This result is disturbing because it implies that embedded software and operating systems — both typically coded in C, both being bases for many mission-critical and safety-critical applications, and both relying on the correct translation of volatiles — may be being miscompiled.   More recently, Regehr, Yang et al. generalized their testing of C compilers and, again, found many instances of miscompilation: We created a tool that generates random C programs, and then spent two and a half years using it to find compiler bugs. So far, we have reported more than 325 previously unknown bugs to compiler developers. Moreover, every compiler that we tested has been found to crash and also to silently generate wrong code when presented with valid inputs.     What sets CompCert apart?   CompCert is the only production compiler that is formally verified, using machine-assisted math­ematical proofs, to be exempt from mis­compilation issues. The code it pro­duces is proved to behave exactly as specified by the semantics of the source C program.     Your benefits   CompCert is a natural complement to any verification tech­niques that you apply at the source-code level — be it model checking, program proof, or static analyzers such as Astrée or RuleChecker. Only with CompCert can you guarantee that all the safety pro­perties verified on the source code also hold for the ge­nerated machine code.   CompCert supports verified separate compilation, enabling large-scale verification of complex software created by many different teams each working on C modules of their own.   When using a conventional compiler to compile safety-critical applications, you typically have to disable compiler optimizations and run into resource problems as a result. With CompCert, you can significantly improve your applications’ performance, as you no longer have to switch off optimizations for safety reasons.   Formally verified optimizations   CompCert implements the following optimizations, all of them formally verified:   Register allocation using graph coloring and iterated register coalescing Instruction selection with strength reduction Constant propagation for integer and floating-point types Common subexpression elimination Dead code elimination Redundant code elimination Function inlining Tail call elimination If-conversion Loop optimizations are currently not performed, but can be implemented on request.   Compilation with execution time in mind   On average, code generated by CompCert is:   twice as fast as code generated by GCC without optimizations, only 10% slower than GCC code at optimization level 1, some 20% slower than GCC code at optimization level 3.   Due to the lack of aggressive loop optimizations, performance is lower for code that involves many matrix computations.   Ease-of-use and interoperability   From command-line options to error messages to the handling of built-in functions, many CompCert features are very deliberately implemented to feel familiar and intuitive to GCC and LLVM users. Another express goal is to generate object code that respects the Application Binary Interface (ABI) of the target platform, and thus can be linked with object code and libraries compiled by other C compilers. In this, CompCert succeeds to a great extent, with some exceptions that are thoroughly documented. CompCert for TriCore is supported by the entire chain of AbsInt tools for safety-critical and mission-critical TriCore applications: Astrée for sound static analysis of your C code RuleChecker for proving compliance with MISRA, CERT, CWE, and other standards ValueAnalyzer for uncovering illegal accesses from within third-party object code StackAnalyzer for static analysis of the worst-case stack usage aiT for safe and precise static WCET analysis TimeWeaver for hybrid WCET analysis TimingProfiler for WCET estimates at early stages of software development   © 2025 AbsInt. Published by JORAL Technologies.

Software Drives Advances in Medical Technology

Software Drives Advances in Medical Technology   Over the last few years, medicine has been a catalyst for driving progress in the innovation of medical devices and treatment plans. There is an emphasis on the extension of lifespans and improving the lives of humans. As there continues to be advances in breakthrough technologies, the introduction of leading-edge medical equipment continues.   There is an emphasis on products that deliver less expensive, faster, more efficient patient care. Digital technology is becoming embedded in every area of healthcare delivery. Medical devices are becoming more and more complex and the benefits of technology innovation to patients and providers is immeasurable.   Health technologies are a key part of the healthcare experience. Artificial intelligence and medical machine learning are assisting medical teams to streamline how patients are treated. Ingestible medical devices with circuits and sensors, have shown to be technologically relevant, in the delivery of drugs and optical imaging for diagnosis of diseases. This extends to both the diagnosis and treating of diseases. Robots are assisting humans in surgery and are assisting doctors in examining and treating patients, transporting medical supplies, and disinfecting hospital rooms. They are also target therapy to specific areas of the body in the case of tumors or bacterial infections.     Machine vision is being utilized for medical diagnostics, viewing of scans and medical images. Neurological and cardiovascular illnesses are widely viewed using computers and resultant diagnosis are made. Virtual reality and augmented reality are beneficial for surgery simulation and training. This also provides education for medical professionals and patients to understand their conditions and plans for ongoing treatments.   The 5G network capability increases the speed to share large imaging files so specialists can view and recommend proper care scenarios. Artificial intelligence, Augmented and Virtual Reality, provides the abilities for remote monitoring of patients.    Medical devices are becoming more complex as the needs for patient treatment solutions increases. It is software embedded in these devices that is increasingly the driver for differentiation and added value. Medical devices are only licensed for use after strict regulatory approvals, and that of course includes the software within them.   IEC 62304:2006 ‘Medical Device Software – Software Life-cycle processes’ is an international harmonized standard for medical devices which contain software, accessories to medical devices that contain software, and “standalone software” that meets the definition of a device or accessory.   In the European Union compliance with IEC 62304 satisfies the Medical Devices Directive 93/42/EEC (MDD) with amendment M5 (2007/47/EC) as related to software development. In the United States, the US FDA will also accept IEC 62304 as evidence that medical device software has been designed to an acceptable standard, and covers following regulatory processes: 510(k), IDE, PMA, HDE, Software Validation (FDA Recognition List Number: 020).   Within IEC 62304 there are requirements for software testing to the highest standards based on the critical nature (Class) of the medical device. So for medical device developers undertaking this software testing it is helpful if they can leverage the existing tools utilized in a development environment to support efficient assemblage of code, and the CI/CD process.   For the unit and integration testing stages in particular, test automation during development is also the most efficient means to meet the verification requirements of the IEC 62304 standard. The thoroughness of these tests also needs to be demonstrated using code coverage. For example, for a Class II (or Class B) device this means achieving 100% coverage of all the decisions in the code. of the code.   Code coverage is not just about demonstrating enough testing but can also lead to code optimization, in removing code that is not required, making the code execute more efficiently.   Project Design and Development Considerations    Control – Medical devices that are software based have a high risk of issues arising later in development or during device validation.   Reduce Uncertainty – With complexity of software development, there needs to be diligence at both the requirements and design phases and throughout the device’s evolution.   Software Tools   – A robust set of software testing and certification tools is important to verify that the code will work properly and to eliminate the issues and monetary losses/damages, and warranty costs associated with faulty equipment operation and patient expiration. – Support the ability for companies to continue to sell their products to the market without the interruptions from lawsuits and product issues in the field. – The tool must provide advanced technical capabilities for: automatic test case generation, control of function calls (e.g., mocking/stubbing), intuitive code coverage and certification evidence and ready results reporting. – A more process-oriented objective is important to ‘shift-left’ software verification activities, finding them early in the project. – Ensures that software tests are created to the required standard, and follow the tool’s Safety Manual guidance for their development and execution. – The Graphical User Interface (GUI) should support a tree view which is vital for assessing test case values with the ability to edit test cases in the user interface to save time with typing.   Summary   Advances in medical equipment are happening every second in every day. There is a need to support the operational aspects of this equipment utilizing fully tested C and C++ code that is verified to the IEC 62304 standard. This is important in support of the diagnosis of illnesses, and saving patient’s lives, taking advantage of the innovative technology available today, which includes vision and artificial intelligence. The depth and robustness of testing capabilities within Cantata the unit & integration testing tool from QA Systems, make it a logical choice, to be part of the medical device software development process. The ever-increasing demands of technology and the importance of quality software, dictates the requirement for a higher and deeper level of testing. Cantata supports these requirements is pre-certified as a class T2 tool for use under IEC 62304 up to Safety Class III (C) and provides the evidence to achieve the required level of software safety certification for medical devices.   © 2025 QA Systems. Published by JORAL Technologies.

Powering the Future: IEC 60880 Compliance in Nuclear Systems and Software Safety

Powering the Future: IEC 60880 Compliance in Nuclear Systems and Software Safety   Why the Nuclear Industry Can’t Afford Software Mistakes   In Nuclear Software, Trust Is Measured in Verification   In the control room of a nuclear plant, quiet confidence is built not on chance but on evidence. Every signal monitored and every line of code executed has a direct link to safety, reliability, and public trust.For decades, the nuclear and energy sectors have operated under one unwavering principle: there can be no margin for error.   Today, however, software, not steel, has become the true guardian of this principle. Reactors, turbines, and redundant control systems all rely on millions of lines of embedded C and C++ code, each of which is a potential point of failure. As regulations tighten and scrutiny deepens, the question is no longer “Can we automate this system?” but “How can we prove that it’s safe?”   That’s where engineered assurance tools like Cantata and QA-MISRA step in, bridging the gap between complex software design and demonstrable functional safety compliance in nuclear systems.   Testing What Matters Most with Cantata   Cantata does more than test code, it tests integrity.Purpose-built for unit and integration testing of embedded C and C++ software, Cantata automates test generation and execution directly at the source level. Each function, decision, and safety path can be verified against its expected behaviour, helping engineers satisfy IEC 60880, IEC 61508, and ISO 26262 standards.   Instead of treating testing as a late-stage hurdle, QA Systems empowers teams to embed verification within the development workflow. When a Cantata test passes, it validates not only the code but also the safety case behind it.   Key capabilities: - Automated unit and integration test generation - Rigorous code coverage analysis (statement, branch, MC/DC) - Full requirements traceability and auditable reporting - Independent TÜV certification for use in nuclear-grade applications   From Compliance in Nuclear Systems to Confidence with QA-MISRA   Compliance is non-negotiable in safety-classified software. Beyond functional correctness, every line of code must behave predictably under all conditions.QA-MISRA enforces MISRA C, MISRA C++, AUTOSAR C++14, and CERT C/C++ standards through automated static analysis, ensuring that unsafe constructs are detected and eliminated long before execution.   Key advantages: - Rapid static analysis across MISRA, AUTOSAR, CERT, and CWE rulesets - Near-zero false positives for syntactic rules - Certified by SGS TÜV for use in IEC 60880 environments - Detailed compliance reports, metrics, and visualisations - Seamless integration into Eclipse IDE and modern CI/CD pipelines With QA-MISRA, software quality becomes measurable, traceable, and certifiable — the foundation of safety-critical integrity.   A Unified Workflow for Functional Safety By combining QA-MISRA (for static analysis and coding-standard compliance) with Cantata (for dynamic testing and code coverage), engineering teams deliver a unified verification workflow that links coding-standard enforcement with automated test validation for full traceability, moving from reactive testing to proactive software assurance, where safety and reliability are built into design, not added at the end.   Specific Support for IEC 60880 Certification The IEC 60880 standard defines the functional safety requirements for software used in nuclear power-plant instrumentation and control systems. QA Systems’ tools provide certification-ready support tailored to these requirements.   Dedicated IEC 60880 toolkits include: - Qualification and certification evidence kits for both Cantata and QA-MISRA - Automated test suites and documentation for audit support - Sequential verification flow: static analysis first (QA-MISRA), then dynamic testing (Cantata) - Direct integration into safety lifecycle processes Both tools are independently certified and designed for the highest Safety Integrity Levels (SILs) demanded by nuclear and high-energy systems.   A Future Built on Proven Integrity As new-generation reactors, small modular systems, and hydrogen-based power emerge, the software controlling them must evolve, but never at the expense of safety.QA Systems provides a verified foundation of trust, giving regulators verifiable evidence, engineers confidence to innovate, and the public assurance that the systems powering their world are as safe as they are sophisticated. In a domain where milliseconds and microcodes separate stability from catastrophe, QA Systems ensures that trust is not a promise, it’s verified, certified, and proven line by line. For more information about QA-MISRA and Cantata, visit qa-systems.com. Author: Dylan Llewellyn   © 2025 QA Systems. Published by JORAL Technologies.

From EN 50128 to EN 50716: The new Era of Railway Software Compliance

From EN 50128 to EN 50716: The New Era of Railway Software Compliance   The railway software compliance landscape has fundamentally shifted.   If your organization still works under EN 50128 or EN 50657, it’s time to adapt to EN 50716:2023, the new unified standard that governs all railway software development and verification activities. Replacing both EN 50128:2011 (control & signalling) and EN 50657:2017 (on-board rolling stock), EN 50716 establishes one comprehensive framework for the entire railway domain. Both predecessor standards were withdrawn in November 2023. While EN 50716 isn’t retrospective, all upgrades and maintenance activities initiated after its publication should align with its requirements In consequence, teams must balance maintaining legacy systems with developing new projects under tighter, better-defined compliance expectations.   Key Requirements That Redefine Railway Software Testing   Section 6.7Support Tools and Languages EN 50716 increases the emphasis on tool qualification and justification. Verification and validation tools must be classified as T1, T2, or T3 based on their potential to introduce undetected faults. T2 Tools (e.g. Cantata) support verification of executable code and therefore require documented justification when used for SW-SIL 1–4. Clause 6.7.4.2 states clearly: “The selection of the tools in classes T2 used for SIL 1 to SIL 4 and T3 used for SIL 1 to SIL 4 shall be justified.”   Table A.5Software Component Analysis and Testing At SW-SIL 4, dynamic testing with comprehensive coverage is mandatory. The table explicitly lists combinations of techniques that must be applied to achieve full confidence in safety-critical behaviour.   Section 6.5.4.14Traceability Traceability must extend from requirements to design, implementation, and all testing phases. Verification evidence should show complete bi-directional links between requirements, design artefacts, and executed tests.   Section 9.2Software Maintenance Regression testing is not optional. Requirements 9.2.4.8 and 9.2.4.10 demand documentation of test re-execution and reuse of updated tests during re-validation. Given that railway systems often operate for more than 20 years, this lifecycle view is essential. Cantata’s Certified Advantage Independently certified by SGS-TÜV GmbH, Cantata is officially recognised as: Class T2 tool meeting EN 50716 sub-clause 6.7 Qualified for use up to SW-SIL 4, the highest Safety Integrity Level Each version of Cantata undergoes independent assessment, with defined behaviour, documented constraints, and mitigation strategies for potential failure modes.   Certification vs Qualification: The Cost Reality Self-qualifying a T2 tool under 6.7.4.5 requires extensive documentation: validation records, tool manual versions, test cases, pass/fail results, and discrepancy analyses. This often translates into weeks of engineering effort per release. With pre-certified Cantata, justification is immediate: Independent TÜV certificate Tool Certification Kit supplied Zero qualification overhead Traceability and Regression. Assurance That Scales Cantata Trace enables full bi-directional requirements traceability: Import from Excel, DOORS, PTC Integrity, Polarion, or Visure Requirements ALM Link requirements directly to Cantata test cases and coverage data Export verification status back to your requirements management tool (RM) for audit readiness When auditors ask for evidence of “REQ-123”, teams can deliver linked test results, execution status, and coverage metrics in minutes, not days. Cantata Code Change Analysis automates regression impact detection: Identifies modified functions Maps affected tests Suggests updates and refactors scripts automatically Supports push-button re-execution through Cantata Makefiles This aligns directly with EN 50716 §9.2.4.8 requirements for test re-execution and artefact control. Why Cantata for EN 50716 Certification Confidence TÜV-certified tool for EN 50716 up to SW-SIL 4 Eliminates tool-qualification burden (§6.7.4.5) Each release is independently certified Complete Technical Coverage Supports all Table A.5 component-testing techniques Addresses Table A.6 integration requirements Meets Table A.21 coverage criteria Enables deep white-box verification Cantata Hybrid option for teams using GoogleTest/GoogleMock who need EN 50716 compliance Lifecycle Support CLI automation for modern DevOps workflows (including VSCode, Jenkins, GitLab CI/CD) Automated regression testing for 20+ year maintenance cycles Bi-directional traceability and audit evidence on demand The Risk Mitigation Reality Section 6.7 is unambiguous: verification tools can introduce latent defects, and their qualification status is critical to certification schedules. Using Cantata means: Tool justification in days, not months Certification body acceptance through SGS-TÜV credentials Straightforward audit defence: “We used an independently certified tool per 6.7.4.2.” Attempting self-qualification adds cost, risk, and schedule uncertainty to every project. As the industry moves from fragmented frameworks to unified assurance, EN 50716 marks a new era of integrated railway software compliance.   Conclusion EN 50716:2023 redefines what safety means in railway software. Tool certification, dynamic testing, traceability, and regression are no longer optional, they are the foundation of compliance. Manual verification simply cannot keep pace with the technical and administrative demands of SW-SIL 3 and 4 projects. With Cantata, engineering teams can bridge modern development practices with the rigorous assurance required by the new standard, achieving compliance without compromising productivity. For railway software teams navigating the EN 50716 transition, the question has shifted: it’s no longer whether to automate verification and validation; it’s whether you can meet certification deadlines without it. For more information about QA-MISRA and Cantata, visit qa-systems.com. Author: Praveen Melepurath   © 2025 QA Systems. Published by JORAL Technologies.

25.10 Release of AbsInt Tools for Safety-Critical Software Development

 All tools =========== - The AbsInt Linux tools require now RHEL 9 or compatible and ship a Dockerfile creating   a compatible Rocky Linux 9 container to facilitate deployment in containerized environments    aiT, TimingProfiler, StackAnalyzer, TimeWeaver ================================================== - NEW: aiT for TI TMS320F28386D/4D/8D - NEW: aiT for ATSAME51J18/19/20A - NEW: aiT for TMS570LC4357 rev B - Improved Project/Workspace Diff-Viewer, Sections View and Symbols View - Enhanced analysis setup capabilities enable users to create new analysis projects   more efficiently    Astrée, RuleChecker ====================== - NEW: Delta analysis displays summary of differences between project revisions   by tables and charts, and classifies alarms as new/old. - NEW: Astrée supports sound analysis of bounded recursions - Enhanced safety manual by DO-356A and ISO 21434 verification goal coverage - Enhanced VS-Code plugin (LSP server) by "single translation unit" mode,   enabling faster rule checking - Improved rule coverage of CERT C/C++ and CWE    CompCert ============ - NEW: CompCert for TriCore (1.6.x) - Improved optimizations for arithmetic runtime library functions - Generation of position-independent executables (PIE) and position-independent code   (PIC) for AArch64, RISC-V and x86-64.    Plugins ========= - AbsInt toolbox for TargetLink supports "diff" mode as default alarm comment mode

CMSIS Debugger: KEIL MDK V6 User Based License

The CMSIS Debugger is a next generation, standards based debugging solution designed to integrate seamlessly into modern embedded development workflows. Built on the trusted CMSIS (Cortex Microcontroller Software Interface Standard) ecosystem, it delivers powerful debugging, trace and analysis capabilities for Arm Cortex-M based devices.   👉 You can find the CMSIS Debugger extension directly in the VS Code Extensions Marketplace, or download it from this link: CMSIS Debugger Extension   ·  Seamless Integration: CMSIS Debugger plugs directly into popular IDEs like Keil MDK, VS Code, and other CMSIS-based workflows. Start debugging without the hassle of extra setup.   ·         Single & Multi-core Support: Offers robust debugging for both single-core and complex multi-core processor systems.   ·         RTOS Awareness: Native support for FreeRTOS, RTX, ThreadX, and Zephyr ensures visibility into tasks, threads, and real-time performance.   ·         Wide Adapter Compatibility: Works with a broad range of debug adapters including ULINK, MCULink, NuLink, J-Link, and ST-Link.   ·         Unified Workflow: Works closely with the CMSIS Toolbox and CMSIS Pack system, simplifying device configuration, board selection, and debug initialization.   ·         Advanced Debug Features: Provides real-time trace, easy code stepping, and comprehensive register/memory inspection across thousands of supported microcontrollers.   ·         Open-Source & Extensible: Fully open-source, it can be combined with other VS Code debug extensions (e.g., Linux application debugging) and extended for domain specific use cases.   ·         Automation & CI/CD Ready: Combined with Arm Virtual Hardware (AVH), CMSIS Debugger enables cloud-based workflows, automated testing, and DevOps pipelines without requiring physical hardware.   The CMSIS Debugger empowers developers to accelerate embedded software development with a flexible, standardized, and powerful debug experience. Whether in early prototyping, safety critical validation, or large-scale CI/CD environments, it ensures consistent results and faster time to market.       To purchase, KEIL MDK V6 Essential User Based License 1 Year & KEIL MDK V6 Professional User Based License 1 Year   By: Hrutik Champaneri  

New Arm Product Updates Available

The following products have been updated: Product Code Product Version MDK000 Keil MDK (Keil Licensing) r5p42-01rel0 - MDK001 Keil MDK (FlexNet) r5p42-01rel0 -

New Arm Product Updates Available

The following products have been updated:   Product Code Product Version DEVST-GLD0 Development Studio UBL Gold r25p0-00rel0 This release of Arm Development Studio includes the next-generation Arm Toolchain for Embedded Professional (ATfEP) in addition to Arm Compiler for Embedded 6 (AC6). Please be aware that consequently Development Studio installation time has significantly increased on Windows. For convenience of Windows users, we provide two installation packages, one that incudes ATfEP and one that does not include ATfEP. We are working to reduce the Windows installation time in future releases. DEVST-GLDF Development Studio UBL Gold FUSA r25p0-00rel0 This release of Arm Development Studio includes the next-generation Arm Toolchain for Embedded Professional (ATfEP) in addition to Arm Compiler for Embedded 6 (AC6). Please be aware that consequently Development Studio installation time has significantly increased on Windows. For convenience of Windows users, we provide two installation packages, one that incudes ATfEP and one that does not include ATfEP. We are working to reduce the Windows installation time in future releases. DS000B Arm Development Studio r25p0-00rel0 This release of Arm Development Studio includes the next-generation Arm Toolchain for Embedded Professional (ATfEP) in addition to Arm Compiler for Embedded 6 (AC6). Please be aware that consequently Development Studio installation time has significantly increased on Windows. For convenience of Windows users, we provide two installation packages, one that incudes ATfEP and one that does not include ATfEP. We are working to reduce the Windows installation time in future releases.