EEVblog® Electronics Community Forum
Electronics => Microcontrollers => Topic started by: bonzer on October 11, 2024, 03:25:30 pm
-
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.
-
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.
-
It is the EN60730-2, table H, software safety class C. Typically used for heating systems.
-
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.
-
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.
-
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.
-
I've done register self-tests (incl. program counter for stuck bits, which is actually a really weird thing to do)
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.
Can you share the link?
-
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.
-
1. Find an open source risc v verification ip
2. Change the instructions to the equivalent arm
3. Compile to verilator c
Someone try this
-
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.
.text
.global test_opcodes
test_opcodes:
; Registers back up
PUSH {R0, R1}
; MOV, CMP and B opcodes
MOV R0, #0xB2
CMP R0, #0xB2
BNE fault_exit
; ADD opcode
ADD R0, R0, #0x13
CMP R0, #0xC5
BNE fault_exit
; SUB opcode
SUB R0, R0, #0xB1
CMP R0, #0x14
BNE fault_exit
; Registers roll back
POP {R0, R1}
; Return
MOV PC, LR
Regarding 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/ (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.
-
It is the EN60730-2, table H, software safety class C. Typically used for heating systems.
Does 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.
-
NXP has a thourough presentation on this interesting subject:
https://www.nxp.com/docs/en/supporting-information/WBNR_FTF10_ENT_F0714.pdf (https://www.nxp.com/docs/en/supporting-information/WBNR_FTF10_ENT_F0714.pdf)
It 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.
-
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.