Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Added support for second core of the amc board #328

Merged
merged 2 commits into from
Dec 19, 2022
Merged

Added support for second core of the amc board #328

merged 2 commits into from
Dec 19, 2022

Conversation

marcoaccame
Copy link
Contributor

@marcoaccame marcoaccame commented Dec 19, 2022

This PR adds support and example applications for code which runs on the CM4 core of the amc board.

This code must not interfere with the code running on the CM7 core of the amc, so something different must be done. That is explained in the next section Bootstrap 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 the eLoader, which decides which binary to jump to;

  • for maintenance it jumps to the eUpdater,
  • for normal execution it jumps to the eApplication.

The second core, the CM4, is fully reserved to run the c2Application which is aimed to cooperate with the eApplication to perform some tasks. For instance in the amc, the c2Application will perform control of a BLDC motor and will talk to the eApplication by means of inter-core-communication methods.

On the other hand, there will not any need for thec2Application to interact with the eUpdater and rather it is best to keep it in idle because the eUpdater 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.

flowchart BT   

    R((RESET))
    S(( ))
	CM4g(("gated"))
	CM4s(("start"))
    CM4w(("locked"))
    
    S -->|power up| R
    R --> eldr
    R --> CM4g
    CM4s --> CM4w
    
    subgraph eldr [eLoader]
 
    end  

    subgraph eupdt [eUpdater]
  
    end 
    
    subgraph eapp [eApplication]
 
    end    
    
    subgraph cm7 [CM7]
        eldr
        eupdt
        eapp
    end

    subgraph c2app [c2Application]

    end    

    
    subgraph cm4 [CM4]
        CM4g
        CM4s
        CM4w
        c2app 
    end
    
    subgraph H7 [STM32H7]
        cm7
        cm4         
    end
    


    CM4w --> c2app
    eldr --> CM4s
    eapp -->|unlock| CM4w

    style S fill:#f9f,stroke:#333,stroke-width:4px
    style R fill:#bbf,stroke:#f66,stroke-width:2px,color:#fff,stroke-dasharray: 5 5
Loading

Figure 1. At exit of RESET the CM4 core is kept gated. The CM7 instead executes the eLoader which in turns jumps to the eUpdater or to the eApplication. The CM4 core is waken up by the eLoader 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 the eApplication, when it runs, to unlock the CM4 which will be able to run the c2Application.

The details

The dual core ETH boards, such as the amc, are based onto the STM32H7 family of MPUs which have independent CM7 and CM4 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 the CM4 (aka idle). So, the CM4 will not execute any code, unless an explicit instruction from the CM7 code enables it.

flowchart BT   

    R((RESET))
    S(( ))
	CM7m("main() { .. }")
	CM4g("gated")
	
    S -->|power up| R
    R --> cm7
    R --> cm4
    
    subgraph cm7 [CM7 core]
        CM7m
    end
    
    subgraph cm4 [CM4 core]
        CM4g 
    end

    subgraph per [HW PERIF]
        CLOCKS
        BUSES
        RAM 
        FLASH
        ...
    end    
    
    subgraph H7 [STM32H7]
        cm4
        cm7
        per     
    end
    
    style S fill:#f9f,stroke:#333,stroke-width:4px
    style R fill:#bbf,stroke:#f66,stroke-width:2px,color:#fff,stroke-dasharray: 5 5
Loading

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 the CM4 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 the CM4 idle (or in a safe execution mode) when the eUpdater runs because we may need to update the code space used by the CM4.

@marcoaccame marcoaccame self-assigned this Dec 19, 2022
@marcoaccame marcoaccame marked this pull request as draft December 19, 2022 16:32
@marcoaccame marcoaccame marked this pull request as ready for review December 19, 2022 20:01
@marcoaccame marcoaccame merged commit 5fef187 into robotology:devel Dec 19, 2022
valegagge pushed a commit to valegagge/icub-firmware that referenced this pull request May 5, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

1 participant