Difference between revisions of "CoreLink SSE-200 Subsystem for MPS3"

From SEGGER Wiki
Jump to: navigation, search
Line 25: Line 25:
 
|Secondary core that is not booted by default on reset release
 
|Secondary core that is not booted by default on reset release
 
|}
 
|}
 
 
   
 
== J-Link device selection ==
 
== J-Link device selection ==
Line 51: Line 49:
 
The sample project for SEGGER Embedded Studio is a RAM based project and also demonstrates multi-core debugging.
 
The sample project for SEGGER Embedded Studio is a RAM based project and also demonstrates multi-core debugging.
 
The sample is actually split into 2 projects:
 
The sample is actually split into 2 projects:
* ARM_SSE-200-MPS3_MPS3_LEDBlinkCore0_ES.emProject
+
* ARM_SSE-200-MPS3_MPS3_LEDBlinkCore0_ES.zip
* ARM_SSE-200-MPS3_MPS3_LEDBlinkCore1_ES.emProject
+
* ARM_SSE-200-MPS3_MPS3_LEDBlinkCore1_ES.zip
   
 
''' ARM_SSE-200-MPS3_MPS3_LEDBlinkCore0_ES '''
 
''' ARM_SSE-200-MPS3_MPS3_LEDBlinkCore0_ES '''
Loaded into internal SRAM and executed by core 0
+
Loaded into internal SRAM and executed by core 0. Controls LED1 and LED2 on the MPS3 board. LED1 is always toggled, LED2 is toggled as long as core 1 is running its application and sending commands to core 0
  +
 
''' ARM_SSE-200-MPS3_MPS3_LEDBlinkCore1_ES '''
 
''' ARM_SSE-200-MPS3_MPS3_LEDBlinkCore1_ES '''
  +
Loaded into internal SRAM and executed by core 1. Sends commands to core 0 that instruct the main application to toggle LED2
   
  +
=== Usage ===
  +
* Start Embedded Studio twice
  +
* Open ARM_SSE-200-MPS3_MPS3_LEDBlinkCore0_ES and ARM_SSE-200-MPS3_MPS3_LEDBlinkCore1_ES accordingly
  +
* Start debug session with project for core 0
  +
* Let CPU run as soon as main() has hit
  +
* Start debug session with project for core 1
  +
* Let CPU run as soon as main() has hit
  +
* LED1 and LED2 will blink
  +
* Now halt core 1 (issue halt request in debug session for core 1)
  +
* LED2 stops blinking, LED1 continues to blink
   
  +
=== Requirements ===
The STM32 Series is a popular family of Cortex-M devices by STMicroelectronics.
 
The following article contains information which applies to all members of the product family (e.g. readout protection).
+
The following are the min. requirements to run the example project:
  +
* SEGGER Embedded Studio V3.40 or later
Information which is more specific to the respective sub-family(e.g. QSPI programming) is provided in family specific articles.
 
  +
* J-Link software V6.33h or later. (Install after Embedded Studio and let J-Link installer update the Embedded Studio installation)
 
  +
* [[MPS3 | ARM MPS3 board]]
A list of all ST devices supported by SEGGER can be found [https://www.segger.com/jlink_supported_devices.html?m=ST#sel here].
 
For further information regarding the STM32 product family, please refer to the website and documentation by STMicroelectronics.
 
 
= MCU Security =
 
 
== Allow opt bytes device selection ==
 
The "allow opt. bytes" device selection is only available for STM32F1 series devices. For later devices, memory mapped programming of the option bytes is not feasible as for some series, the option bytes become valid immediately which would cause immediate connection loss to a device (in case readout protection is enabled) before the option byte programming can be verified.
 
 
The STM32 series devices provide option bytes which allow "permanent" configuration as well as readout protection for the device.
 
In order to enable or disable readout protection, a sequence of multiple read / write accesses to special function registers of the STM32 MCU has to be performed.
 
The sequence is different for each sub-family of the STM32 device series and is described in the respective reference manual of the device.
 
A list of example J-Link commander files and J-Flash projects which enable or disable the readout protection of an STM32 device is provided below.
 
Please note that the provided files serves as an example / proof of concept. A user may alter them in order to suit their specific use case, e.g. using smaller timeouts, programming other values, etc.
 
 
== Disabling readout protection ==
 
 
=== J-Link Commander and J-Flash ===
 
J-Link Commander and J-Flash automatically detect secured STM32 devices and ask the user if it should be unlocked. Further information regarding this can be found here: [[Secured_ST_device_detected]]
 
 
=== Flasher standalone mode ===
 
In order to unlock a STM32 device in stand-alone mode, the unlock sequence needs to be configured in the init steps of the J-Flash project (see examples in the table below).
 
 
=== Restoring factory defaults ===
 
The standalone software tool STM32 Unlock can be used to reset the Option Bytes of a STM32 device to factory default settings.
 
STM32 Unlock is part of the [https://www.segger.com/jlink-software.html J-Link software & documentation pack].
 
 
== Enabling readout protection ==
 
 
All provided J-Link Commander command files and J-Flash projects set the read out protection to level 1 (ROP == Level 1).
 
In order to set ROP Level 2, the value "0xBB" needs to be changed to "0xCC" where indicated in the command file / Exit steps of the J-Flash project.
 
Please note that ROP Level 2 is permanent and can neither be reverted by SEGGER nor by ST.
 
 
{| class="wikitable"
 
|+STM32 series overview
 
! Sub-Family
 
! Core
 
! J-Link Commander and J-Flash:<br> native Unlock support
 
! J-Link Commander:<br> Lock via commanderfile
 
! STM32 Unlock tool support
 
! J-Flash:<br> Unlock project
 
! J-Flash<ref>For further information regarding native support in J-Flash and why native support is no longer implemented for new devices, please refer to this article: [[MCU_Security_Options]]</ref>:<br> native lock support
 
! J-Flash:<br> Lock project
 
|-
 
|STM32F0
 
|Cortex-M0
 
|scope="col" style="text-align:center" | [[File:YES.png|20px|link=]]
 
|[[:Media:STM32F0_Lock.jlink | STM32F0_Lock.jlink]]
 
|scope="col" style="text-align:center" | [[File:YES.png|20px|link=]]
 
|[[:Media:STM32F0_Unlock.jflash|STM32F0_Unlock.jflash]]
 
|scope="col" style="text-align:center" | [[File:YES.png|20px|link=]]
 
|[[:Media:STM32F0_Lock.jflash|STM32F0_Lock.jflash]]
 
|-
 
|STM32F1
 
|Cortex-M3
 
|scope="col" style="text-align:center" | [[File:YES.png|20px|link=]]
 
|[[:Media:STM32F1_Lock.jlink|STM32F1_Lock.jlink]]
 
|scope="col" style="text-align:center" | [[File:YES.png|20px|link=]]
 
|[[:Media:STM32F1_Unlock.jflash|STM32F1_Unlock.jflash]]
 
|scope="col" style="text-align:center" | [[File:YES.png|20px|link=]]
 
|[[:Media:STM32F1_Lock.jflash|STM32F1_Lock.jflash]]
 
|-
 
|STM32F2
 
|Cortex-M3
 
|scope="col" style="text-align:center" | [[File:YES.png|20px|link=]]
 
|[[:Media:STM32F2_Lock.jlink|STM32F2_Lock.jlink]]
 
|scope="col" style="text-align:center" | [[File:YES.png|20px|link=]]
 
|[[:Media:STM32F2_Unlock.jflash|STM32F2_Unlock.jflash]]
 
|scope="col" style="text-align:center" | [[File:YES.png|20px|link=]]
 
|[[:Media:STM32F2_Lock.jflash|STM32F2_Lock.jflash]]
 
|-
 
|STM32F3
 
|Cortex-M4
 
|scope="col" style="text-align:center" | [[File:YES.png|20px|link=]]
 
|[[:Media:STM32F3_Lock.jlink|STM32F3_Lock.jlink]]
 
|scope="col" style="text-align:center" | [[File:YES.png|20px|link=]]
 
|[[:Media:STM32F3_Unlock.jflash|STM32F3_Unlock.jflash]]
 
|scope="col" style="text-align:center" | [[File:YES.png|20px|link=]]
 
|[[:Media:STM32F3_Lock.jflash|STM32F3_Lock.jflash]]
 
|-
 
|[[STM32F4]]
 
|Cortex-M4
 
|scope="col" style="text-align:center" | [[File:YES.png|20px|link=]]
 
|[[:Media:STM32F4_Lock.jlink|STM32F4_Lock.jlink]]
 
|scope="col" style="text-align:center" | [[File:YES.png|20px|link=]]
 
|[[:Media:STM32F4_Unlock.jflash|STM32F4_Unlock.jflash]]
 
|scope="col" style="text-align:center" | [[File:YES.png|20px|link=]]
 
|[[:Media:STM32F4_Lock.jflash|STM32F4_Lock.jflash]]
 
|-
 
|[[STM32F7]]
 
|Cortex-M7
 
|scope="col" style="text-align:center" | [[File:YES.png|20px|link=]]
 
|[[:Media:STM32F7_Lock.jlink|STM32F7_Lock.jlink]]
 
|scope="col" style="text-align:center" | [[File:YES.png|20px|link=]]
 
|[[:Media:STM32F7_Unlock.jflash|STM32F7_Unlock.jflash]]
 
|scope="col" style="text-align:center" | [[File:NO.png|20px|link=]]
 
|[[:Media:STM32F7_Lock.jflash|STM32F7_Lock.jflash]]
 
|-
 
|STM32H7
 
|Cortex-M7
 
|N/A
 
|N/A
 
|scope="col" style="text-align:center" | [[File:NO.png|20px|link=]]
 
|N/A
 
|scope="col" style="text-align:center" | [[File:NO.png|20px|link=]]
 
|N/A
 
|-
 
|STM32L0
 
|Cortex-M0
 
|scope="col" style="text-align:center" | [[File:YES.png|20px|link=]]
 
|[[:Media:STM32L0_Lock.jlink|STM32L0_Lock.jlink]]
 
|scope="col" style="text-align:center" | [[File:YES.png|20px|link=]]
 
|[[:Media:STM32L0_Unlock.jflash|STM32L0_Unlock.jflash]]
 
|scope="col" style="text-align:center" | [[File:YES.png|20px|link=]]
 
|[[:Media:STM32L0_Lock.jflash|STM32L0_Lock.jflash]]
 
|-
 
|STM32L1
 
|Cortex-M3
 
|scope="col" style="text-align:center" | [[File:YES.png|20px|link=]]
 
|[[:Media:STM32L1_Lock.jlink|STM32L1_Lock.jlink]]
 
|scope="col" style="text-align:center" | [[File:YES.png|20px|link=]]
 
|[[:Media:STM32L1_Unlock.jflash|STM32L1_Unlock.jflash]]
 
|scope="col" style="text-align:center" | [[File:YES.png|20px|link=]]
 
|[[:Media:STM32L1_Lock.jflash|STM32L1_Lock.jflash]]
 
|-
 
|[[STM32L4]]
 
|Cortex-M4
 
|scope="col" style="text-align:center" | [[File:YES.png|20px|link=]]
 
|[[:Media:STM32L4_Lock.jlink|STM32L4_Lock.jlink]]
 
|scope="col" style="text-align:center" | [[File:YES.png|20px|link=]]
 
|[[:Media:STM32L4_Unlock.jflash|STM32L4_Unlock.jflash]]
 
|scope="col" style="text-align:center" | [[File:NO.png|20px|link=]]
 
|[[:Media:STM32L4_Lock.jflash|STM32L4_Lock.jflash]]
 
|}
 
 
All command files and J-Flash projects have a specific MCU selected.
 
For the sole purpose of locking the device via J-Link commander changing of the device name is not necessary,
 
<!-- See http://forum.segger.com/index.php?page=Thread&threadID=4150 -->
 
'''but it is mandatory to change the device name to the actual device used when using J-Flash or doing any flash programming in J-Link commander.'''
 
 
Please note that securing a device via J-Link command files is limited in a way that interpretation of return values,
 
if / else branches etc. are not available. Therefore, production programming and securing of devices can only be done with
 
J-Flash or the J-Link SDK.
 
In any case, it is the responsibility of the user to verify that the required read out protection is active before the programming device leaves the production facility.
 
   
 
<references/>
 
<references/>

Revision as of 11:03, 4 July 2018

The ARM CoreLink SSE-200 is a prototyping platform from ARM that allows prototyping of Cortex-M33 based devices on the ARM MPS3 board. It incorporates a dual-core Cortex-M33, lots of internal RAM (> 2 MB) and QSPI flash.

J-Link support

J-Link supports the ARM CoreLink SSE-200 prototyping platform since the following J-Link software versions:

  • V6.33h (beta) or later
  • V6.34 (release) or later

Download latest beta

Download latest release

Core topology

The cores are named as follows:

Core name Description
Cortex-M33 (core 0) Main core that device boots from by default
Cortex-M33 (core 1) Secondary core that is not booted by default on reset release

J-Link device selection

The following device names are available for J-Link:

Device name Function
SSE-200-MPS3 Connects to core 0
SSE-200-MPS3_M33_0 Connects to core 0
SSE-200-MPS3_M33_1 Connects to core 1. Core 1 is enabled (released from reset) automatically by J-Link, if necessary

Example projects

There are sample projects available that demonstrate how to use J-Link with the ARM CoreLink SSE-200 prototyping platform.

SEGGER Embedded Studio (multi-core)

The sample project for SEGGER Embedded Studio is a RAM based project and also demonstrates multi-core debugging. The sample is actually split into 2 projects:

  • ARM_SSE-200-MPS3_MPS3_LEDBlinkCore0_ES.zip
  • ARM_SSE-200-MPS3_MPS3_LEDBlinkCore1_ES.zip

ARM_SSE-200-MPS3_MPS3_LEDBlinkCore0_ES Loaded into internal SRAM and executed by core 0. Controls LED1 and LED2 on the MPS3 board. LED1 is always toggled, LED2 is toggled as long as core 1 is running its application and sending commands to core 0

ARM_SSE-200-MPS3_MPS3_LEDBlinkCore1_ES Loaded into internal SRAM and executed by core 1. Sends commands to core 0 that instruct the main application to toggle LED2

Usage

  • Start Embedded Studio twice
  • Open ARM_SSE-200-MPS3_MPS3_LEDBlinkCore0_ES and ARM_SSE-200-MPS3_MPS3_LEDBlinkCore1_ES accordingly
  • Start debug session with project for core 0
  • Let CPU run as soon as main() has hit
  • Start debug session with project for core 1
  • Let CPU run as soon as main() has hit
  • LED1 and LED2 will blink
  • Now halt core 1 (issue halt request in debug session for core 1)
  • LED2 stops blinking, LED1 continues to blink

Requirements

The following are the min. requirements to run the example project:

  • SEGGER Embedded Studio V3.40 or later
  • J-Link software V6.33h or later. (Install after Embedded Studio and let J-Link installer update the Embedded Studio installation)
  • ARM MPS3 board