Added support for second core of the amc
board
#328
Merged
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This PR adds support and example applications for code which runs on the
CM4
core of theamc
board.This code must not interfere with the code running on the
CM7
core of theamc
, so something different must be done. That is explained in the next sectionBootstrap of the dual core ETH boards
.Bootstrap of the dual core ETH boards
In here it is described the bootstrap procedure we use on our dual core ETH boards, such as the
amc
.Brief description
The dual core ETH boards run on their first core, the
CM7
, the same binaries that we run on the legacy ETH boards:eLoader
,eUpdater
,eApplication
. At bootstrap it executes theeLoader
, which decides which binary to jump to;eUpdater
,eApplication
.The second core, the
CM4
, is fully reserved to run thec2Application
which is aimed to cooperate with theeApplication
to perform some tasks. For instance in theamc
, thec2Application
will perform control of a BLDC motor and will talk to theeApplication
by means of inter-core-communication methods.On the other hand, there will not any need for the
c2Application
to interact with theeUpdater
and rather it is best to keep it in idle because theeUpdater
will need to update its code space.The adopted solution
The solution which best fit our requirements is anticipated in the following Figure 1. More details follows in the next sections.
Figure 1. At exit of RESET the
CM4
core is kept gated. TheCM7
instead executes theeLoader
which in turns jumps to theeUpdater
or to theeApplication
. TheCM4
core is waken up by theeLoader
just after HW initialization, so that a debugger can attach it it straight away. It is however put in hold almost immediately. It will be theeApplication
, when it runs, to unlock theCM4
which will be able to run thec2Application
.The details
The dual core ETH boards, such as the
amc
, are based onto theSTM32H7
family of MPUs which have independentCM7
andCM4
cores that share the same buses and some other HW peripherals. This sharing of resources requires some coordination.The MPU can be configured with its option bytes so that at exit from RESET the system can bootstrap in several ways. In one of these, the MPU will start only the
CM7
core and keep gated theCM4
(aka idle). So, theCM4
will not execute any code, unless an explicit instruction from theCM7
code enables it.Figure 2. Bootstrap mode with the
CM4
core left gated. To bootstrap in this mode the option bytes must be programmed accordingly.In this mode the
CM7
prepares whatever it must and then it can start theCM4
core. It can start it straight away or only when it really needs it.This is the mode which best fits our requirements. In our boards we need the services of the CM4 core only when the
eApplication
runs. Also, we prefer the keep theCM4
idle (or in a safe execution mode) when theeUpdater
runs because we may need to update the code space used by theCM4
.