Using a HEX code as a part (e.g function or subrutine or library) of another Code on STM32

I have a STM32F103CBT HEX code which is used to unlock hardware. For example, it sends 0xAE12D3B1 to my MCU and after encryption it returns 0x1E47C0A3. If this Data transfer is correct then I have the access to use hardware, else it tries once more until correct answer comes to it. After that I have a STM32F407VGT which handle a lot of tasks like commination with USART, I2C, multiple ADC Channels, PWM, CAN, etc.

How can I use my STM32F103 HEX code as a function or library in my STM32F407 MCU? For example, I should have a multi section code. First it boots HEX and then boots my own code?

It is not clear what you mean by "HEX code". If you mean an Intel Hex format object file, that is just a representation of the binary object code output by your linker.

Both processors are largely binary compatible and code compiled for one will run on the other. The Cortex M4 has additional DSP and floating point instructions, so the code needs to be built for the lowest common denominator.

However the hex file output from your linker is normally fully linked executable and not simply the unlock function in question. It will contain start-up and library code that is not relevant or already exists in the target processor application, and likely very target specific.

To use common code across applications you should either:

• Share the source file across projects and separately compile and link it. The shared source might be in a common directory used by both projects, or more robustly might be shared via a version control system (using git submodules, or Subversion externals for example).
• Separately compile the code without linking and use the resulting object module (.o or .obj), and link that to each project.
• Build a static link library (.a or .lib depending on your toolchain's conventions). And link that to each project. This option is much like linking a .obj, but is more convenient if your code is composed of multiple object files. A static link library is simply a packaged collection of object files.

A hex file is normally a complete fully linked application and not easy to load as an extension to another application or to be extended itself. Runtime loading of object modules is a subject that has come up recently on SO. That is not straightforward either.

For example, I should have a multi section code. First it boots HEX and then boots my own code?

That does not sound like the same question. That sounds like a bootloader. It may make sense to build your access authorisation into a bootloader (or boot without implementing the "loader" functionality) and jump to a separately linked application image if authorisation passes. Either way switching from one application image to another at a separate load address is the function of a bootloader, so even if you are not actually building a bootloader the technique is the same. There are questions on SO specifically about Cortex-M bootloader that may help.