X-CUBE-CRYPTOLIB - how is the CRC peripheral base address set

[anotherandrew]

I'm using X-CUBE-CRYPTOLIB v4.1.0 on an STM32H735. I'm using the libSTM32Cryptographic_CM7.a static library supplied by the crypto library.

I'm running into an interesting issue where the address that the binary library is using for the CRC peripheral is wrong, but only when running under emulation (I'm using Renode.io). Running on the real device does not have this issue. The firmware used in both cases is identical (i.e. I'm loading the same firmware binary into Renode or into the STM32).

For the STM32H735, the CRC peripheral is at 0x58024c00, which is off D3_AHB1. This is all computed in the stm32h735.h header file supplied by the HAL. If I check the macro definitions in my C source, everything lines up correctly.

Tracing around in the assembly code in the crypto library, it looks like cmox_md_generateTag is finding the address of the CRC peripheral through a bit of math, a lookup table and a value passed to it by cmox_hash_common_compute() which is called by cmox_sha224_compute(), which probably got it from cmox_hash_compute() which is the function I call from my source.

Is the library finding the base address of D3_AHB1 through some low level Cortex M connection table? I'd like to add proper support for this into Renode, but need to know where it's coming from.

A little more information: cmox_getInfos() returns the following table, which probably gives someone at ST some more data: {version = 0x40000b1, build = {0xd173a700, 0xd60b5b58, 0xbd0b22be, 0x238a7ff7, 0x8296a668, 0x0, 0x0}}

[anotherandrew · Accepted solution]

Answering my own question: `cmox_initialize()` attempts to find out what chip it's running on by querying `NVIC->CPUID` (and *not* the line identifier at `0x1ff1e8c0` which is located the system memory flash area), then querying some of the ARM ROM tables to end up looking at `DBGMCU->IDC`. Once I modified my Renode configuration to behave the same way the issue went away.