Difference between revisions of "Programming non memory-mapped flash"
(→Programming serial NOR flash) |
(→Programming serial NOR flash) |
||
| (4 intermediate revisions by the same user not shown) | |||
| Line 18: | Line 18: | ||
= Programming serial NOR flash = |
= Programming serial NOR flash = |
||
| − | As the connection between MCU and the serial NOR flash is custom (many MCUs provide multiple SPIs the flash could be connected to), there is |
+ | As the connection between MCU and the serial NOR flash is custom (many MCUs provide multiple SPIs the flash could be connected to), there is no out-of-the box solution available for J-Link to program such flashes indirectly through the MCU and the SPI. There are basically 2 options available for J-Link to program these types of flashes: |
# Direct programming: J-Link is directly connected to the flash, no MCU in between. For more info about the setup, see article [[SPI Flash]]. Programming is done via J-Flash SPI software (for more info, see [https://www.segger.com/products/debug-probes/j-link/tools/j-flash-spi/ J-Flash SPI] |
# Direct programming: J-Link is directly connected to the flash, no MCU in between. For more info about the setup, see article [[SPI Flash]]. Programming is done via J-Flash SPI software (for more info, see [https://www.segger.com/products/debug-probes/j-link/tools/j-flash-spi/ J-Flash SPI] |
||
| + | # Indirect programming: J-Link is connected to the debug interface of the MCU and performs programming by feeding MCU peripherals via a flash loader temporarily downloaded to RAM (RAMCode). For more information about how to write such a flash loader, please refer to [[Adding Support for New Devices]] |
||
| + | |||
| + | == Notes == |
||
| + | * When going for the indirect programming, a virtual address needs to be assigned to the serial NOR flash because all J-Link software is designed for address based flash programming. It is recommended to choose a virtual address for the serial NOR flash that is ''reserved'' in the MCU address space, so there is no overlap with other memories / peripherals etc. |
||
= Programming parallel NAND flash = |
= Programming parallel NAND flash = |
||
| + | As the connection between MCU and the parallel NAND flash is custom (some MCUs provide multiple NAND flash controllers the flash could be connected to), there is no out-of-the box solution available for J-Link to program such flashes indirectly through the MCU and the NAND flash controller. In order to program these devices: J-Link is connected to the debug interface of the MCU and performs programming by feeding the NAND flash controller via a flash loader temporarily downloaded to RAM (RAMCode). For more information about how to write such a flash loader, please refer to [[Adding Support for New Devices]] |
||
| − | TBD |
||
| + | |||
| + | == Notes == |
||
| + | * NAND flashes do not only contain the pure application data but also have a so called '''spare area''' per NAND flash page. In this spare area, some additional information like ECC and bad block markers are placed. This area needs to be handled by the flash algorithm. It cannot be expected that the data for this area is provided by the application image that is programmed. |
||
= Programming serial NAND flash = |
= Programming serial NAND flash = |
||
| + | See [[Programming non memory-mapped flash#Programming parallel NAND flash | Programming parallel NAND flash]] |
||
| − | TBD |
||
| − | |||
| − | The ARM CoreLink SSE-200 is a prototyping platform from ARM that allows prototyping of Cortex-M33 based devices on the [[MPS3 | 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 ([https://www.segger.com/downloads/jlink/#J-LinkSoftwareAndDocumentationPackBeta Download latest beta]) |
||
| − | * V6.34 (release) or later ([https://www.segger.com/downloads/jlink/#J-LinkSoftwareAndDocumentationPack Download latest release]) |
||
| − | |||
| − | = Core topology = |
||
| − | The cores are named as follows: |
||
| − | |||
| − | {| class="wikitable" |
||
| − | !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: |
||
| − | |||
| − | {| class="wikitable" |
||
| − | !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: |
||
| − | * [[Media:ARM_SSE-200-MPS3_MPS3_LEDBlinkCore0_ES.zip | ARM_SSE-200-MPS3_MPS3_LEDBlinkCore0_ES.zip]] |
||
| − | * [[Media:ARM_SSE-200-MPS3_MPS3_LEDBlinkCore1_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 SEGGER 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) |
||
| − | * [[MPS3 | ARM MPS3 board]] |
||
| − | |||
| − | <references/> |
||
Latest revision as of 10:26, 6 September 2018
Contents
There are different types of flash memories available to be connected to an MCU. Some are designed to allow execution in place where the flash is readable by the MCU in its address space (like RAM and peripheral registers are). Some other flashes can only be connected to certain peripherals and be accessed indirectly through the peripheral. These are called "non memory-mapped flashes". In the following some examples for non memory-mapped flashes are given.
| Flash type | MCU connection |
|---|---|
| Serial NOR flash | Connected to a traditional SPI peripheral of the MCU. The flash contents cannot be read directly via memory-mapped accesses. The MCU needs to run an application that feeds the SPI peripheral to get the data from the flash and copy it into some addressable memory (e.g. RAM) |
| Parallel NAND flash | Connected to a NAND flash controller of the MCU. The flash contents cannot be read directly via memory-mapped accesses. The MCU needs to run an application that feeds the NAND flash controller to get the data from the flash and copy it into some addressable memory (e.g. RAM) |
| Serial NAND flash | Connected to a NAND flash controller of the MCU. The flash contents cannot be read directly via memory-mapped accesses. The MCU needs to run an application that feeds the NAND flash controller to get the data from the flash and copy it into some addressable memory (e.g. RAM) |
Programming serial NOR flash
As the connection between MCU and the serial NOR flash is custom (many MCUs provide multiple SPIs the flash could be connected to), there is no out-of-the box solution available for J-Link to program such flashes indirectly through the MCU and the SPI. There are basically 2 options available for J-Link to program these types of flashes:
- Direct programming: J-Link is directly connected to the flash, no MCU in between. For more info about the setup, see article SPI Flash. Programming is done via J-Flash SPI software (for more info, see J-Flash SPI
- Indirect programming: J-Link is connected to the debug interface of the MCU and performs programming by feeding MCU peripherals via a flash loader temporarily downloaded to RAM (RAMCode). For more information about how to write such a flash loader, please refer to Adding Support for New Devices
Notes
- When going for the indirect programming, a virtual address needs to be assigned to the serial NOR flash because all J-Link software is designed for address based flash programming. It is recommended to choose a virtual address for the serial NOR flash that is reserved in the MCU address space, so there is no overlap with other memories / peripherals etc.
Programming parallel NAND flash
As the connection between MCU and the parallel NAND flash is custom (some MCUs provide multiple NAND flash controllers the flash could be connected to), there is no out-of-the box solution available for J-Link to program such flashes indirectly through the MCU and the NAND flash controller. In order to program these devices: J-Link is connected to the debug interface of the MCU and performs programming by feeding the NAND flash controller via a flash loader temporarily downloaded to RAM (RAMCode). For more information about how to write such a flash loader, please refer to Adding Support for New Devices
Notes
- NAND flashes do not only contain the pure application data but also have a so called spare area per NAND flash page. In this spare area, some additional information like ECC and bad block markers are placed. This area needs to be handled by the flash algorithm. It cannot be expected that the data for this area is provided by the application image that is programmed.
