Instructions self-test ARM Cortex-M33 - Page 1
Forum section: electronics / general

author: bonzer
author_rank: Regular Contributor
timestamp: October 11, 2024, 03:25:30 pm
content: Hi everyone, I'm working on the instruction self-test for an ARM Cortex-M33 microcontroller. I previously did this for an STM32 ARM Cortex-M0+ in assembly, which was easy due to its small instruction set. However, the M33 has a much larger set (about 260 instructions), making it a more time-consuming task. Most resources online are paid due to certification requirements. Do you know of any open-source project that could help me get started? It doesn't need to be safety-compliant — I'm just looking for a starting point, even for an ARM Cortex-M4 as long as it covers the complex instructions.

author: uer166
author_rank: Super Contributor
timestamp: October 11, 2024, 09:54:05 pm
content: curious what kind of standard requires instruction testing? I've done register self-tests (incl. program counter for stuck bits, which is actually a really weird thing to do), but never instructions.

author: bonzer
author_rank: Regular Contributor
timestamp: October 12, 2024, 09:42:13 am
content: It is the EN60730-2, table H, software safety class C. Typically used for heating systems.

author: MathWizard
author_rank: Super Contributor
timestamp: October 12, 2024, 12:21:43 pm
content: I've done something with STM32, but just in ArduinoIDE. I just bare-metal programmed an 8-pin ATTiny13A chip do try out the ADC.I have a few BluePill boards, I look forward to seeing what's under their hood. I hope it's not too different.

author: bonzer
author_rank: Regular Contributor
timestamp: October 12, 2024, 02:06:44 pm
content: But were your self-tests limited to the ADC only? It is useful as well but you need external voltage references to be connected to it and sample it. I'm not sure about any devoted instruction that needs to be tested in this case because typically the CPU accesses the ADC through standard load (LDR) and store (STR) instructions that read from or write to specific memory addresses corresponding to the ADC's control and data registers.

author: uer166
author_rank: Super Contributor
timestamp: October 12, 2024, 06:45:44 pm
content: Would be a decent excuse to ask ST about it, they have those libs for some parts for this particular standard already, although it's the F1/F4 and looks like C0. Maybe they have something in the works already.

author: radiolistener
author_rank: Super Contributor
timestamp: October 14, 2024, 02:49:15 am
content: Quote from: uer166 on October 11, 2024, 09:54:05 pmQuote from: bonzer on October 11, 2024, 03:25:30 pmCan you share the link?

author: bonzer
author_rank: Regular Contributor
timestamp: October 15, 2024, 07:07:58 am
content: I don't have it online so I need to look for it on my PC and share it here but I'm currently very busy, sorry guys I'll be back soon.

author: nimish
author_rank: Regular Contributor
timestamp: October 15, 2024, 09:02:30 pm
content: 1. Find an open source risc v verification ip2. Change the instructions to the equivalent arm3. Compile to verilator cSomeone try this

author: bonzer
author_rank: Regular Contributor
timestamp: October 17, 2024, 09:48:56 am
content: I was able to retrieve an initial version of the assembly code that I did in the past to self-test the instructions but it isn't complete. I still want to share it just to give an idea about what I'm talking about.Code:.text.global test_opcodestest_opcodes:; Registers back upPUSH {R0, R1}; MOV, CMP and B opcodesMOV R0, #0xB2CMP R0, #0xB2BNE fault_exit; ADD opcodeADD R0, R0, #0x13CMP R0, #0xC5BNE fault_exit; SUB opcodeSUB R0, R0, #0xB1CMP R0, #0x14BNE fault_exit; Registers roll backPOP {R0, R1}; ReturnMOV PC, LRRegarding the open source RISC-V verification IP path, it sounds like an interesting idea but I'm still not familiar with RISC-V architecture and therefore can't evaluate the effort. It seems to me quite different and challenging in terms of adaptation to the equivalent ARM instruction set.In an effort to maintain granularity in coding of instruction tests by using assembly language, I discovered a tool called Godbolt:https://godbolt.org/. It converts C code into assembly, making it particularly helpful for those less familiar with assembly. If the generated assembly code doesn't include the specific instruction you're looking to test, you can enforce it by including #include <arm_acle.h> and using the corresponding C instruction-functions from the library. For example, the function __sadd16(a, b) translates directly into the SADD16 instruction in the assembly output on Godbolt.

author: SiliconWizard
author_rank: Super Contributor
timestamp: October 17, 2024, 02:17:40 pm
content: Quote from: bonzer on October 12, 2024, 09:42:13 amDoes it imply that you need to verify a CPU correctness as a "user" of said CPU? Can you not rely on the vendor's data? (But maybe they're unable to provide such verification?)Or is it a self-test not meant as proof of correctness in general, but as a verification on each CPU, executed routinely on the device to check that it's still working as intended?I don't know much of the EN60730-2.

author: nctnico
author_rank: Super Contributor
timestamp: October 17, 2024, 03:56:06 pm
content: NXP has a thourough presentation on this interesting subject:https://www.nxp.com/docs/en/supporting-information/WBNR_FTF10_ENT_F0714.pdfIt looks like you'll also need redundant processors with memory ECC to meet class B or class C if you implement safety features entirely in software. A standard microcontroller is not going to match these requirements for sure; it will need to be a microcontroller designed for safety critical applications. At first glance this doesn't look easy and could be a total hell to get certified. My approach would be to implement whatever is safety critical in hardware and adhere to MISRA (or similar standard) as a starting point for good coding practise.

author: bonzer
author_rank: Regular Contributor
timestamp: October 17, 2024, 04:20:08 pm
content: While ARM cores are indeed certified, the related standards don't cover the requirements of the EN 60730-2. ARM has to ensure the systematic integrity like for example hardware design bugs while class C purpose is to detect and react to random hardware faults like for instance an ALU failure caused by degradation over time.The document by NXP seems interesting, I'm gonna have a little read of it later.