FAQs

Check the SE-UART output and see what that is reporting. The usual problem is your application program is misbehaving, to remove it you need to use maintenance mode. Reference the Alif Security Toolkit User Guide.

Using XIP (eXecute In Place) on REV_A1 there are issues with updating MRAM. If you have code executing from MRAM (meaning being read from MRAM) you cannot write to MRAM at the same time. To compensate for this “feature” when doing ISP-based updates, we simply reset the device and force the device into maintenance mode. Once in this mode we have skipped any loading or executing of programs from the MRAM, which means no reading from MRAM – now we are safe to write / update / erase MRAM.

Secure Enclave System (or SERAM as we call it) is the application code launched by SEROM on boot. It is responsible for configuring hardware such as the PLL and then processing the TOC entries in MRAM. After this processing is complete it then enters a servicing mode where it is listening for Service requests from the application CPUs or to ISP commands over the SE-UART.

This error message is reported on SES boot up if no Application TOC image is found in the MRAM. It is technically not an error, rather a warning. It is generated from the SES::bootloader module (hence the BL_ prefix).

This is SEROM output. SEROM uses a lower baud rate than SERAM, what you see is the SEROM Banner output. This is true for SERAM versions below v0.54.0. Later versions use the same baud rate (100000 baud) for SEROM and SERAM.

This is the SERAM Flicker. It cycles through 8 characters every 1 second. It was added early in development to let us know that SERAM is still actually still alive and running! Using maintenance mode option for SERAM Metrics you can display the uptime for SERAM which is the number of milliseconds since SERAM started.

The values reported here show what areas of memory are protected by the Firewall. A typical output would be 0x80580000 – 0x805FFFFF which is an E7 Series device showing the MRAM address range that is protected (it’s the ALIF section!)

Most issues with the tools are related to the python environment setup e.g. 

• Make sure you have installed the extra modules needed by the tools especially the cryptography library. 

• Wherever you have your python3.exe, copy this executable to the same directory but call it python.exe 

If you are trying to run SETOOLS commands in a Linux terminal window that been set up for running the APSS SDK flow including the cross-compiler and GDB debugger, the SDK environment setup script creates an environment that is incompatible with the SETOOLS Python utilities. The SETOOLS should be run in a terminal shell window that is separate for any windows setup up for the APSS SDK flow.

Instructions on installing the Alif Security Toolkit (SETOOLS) are in the Alif Security Toolkit Quick Start Guide.

SETOOLS are a set of host-side applications provided by Alif that are used to communicate with the Secure Enclave to program, provision, update, debug, and recover any Alif Semiconductor processor. Provisioning means to add images to the internal NVM storage (MRAM) as well as adding Security assets such as Keys to the One Time Programmable memory (OTP). Communication between the host and device is done via SE UART.

Alif Semiconductor provides SETOOLS executables for Windows, Linux, and MacOS for Apple Core M-based Macs.

For any other platform (such as Raspberry Pi Linux, arm64 architecture, or Intel-based macOS), customers can request Python scripts, which can be compiled for the required platform.

Most of the SETOOLS have a -v (Verbose) option (See the Alif Security Toolkit User Guide). If you are performing MRAM updates with -v option enabled, you will get a lot of screen output.

Use the updateSystemPackage.py tool in the app-release directory. Only one command is required.

Use the tools-config command to set which part number or revision you want.  

Data structures which contain binaries and device configuration data stored in internal NVM (MRAM) called Application Table of Contents (ATOC) and System Table of Contents (STOC). Alif Semiconductor processors use a Secure Enclave to process these data structures in MRAM to apply system configurations and boot the appropriate CPU cores.

The STOC is provided by Alif and is used to describe Alif binaries and configurations. The STOC is stored in a protected region of NVM storage (MRAM) that cannot be accessed by any core other than the Secure Enclave. This region is only updatable using SETOOLs or over-the-air (OTA) using SE SERVICE APIs.

The ATOC is for user specified application binaries written for A32 or M55 cores and miscellaneous configurations in JSON format. The SETOOLs are used to generate the ATOC. Writing the ATOC to NVM storage (MRAM) can be done using SETOOLs, JTAG, or OTA.

When the ATOC is erased (no data at the top of MRAM), the Secure Enclave checks the base of MRAM for any possible application binary. If one is found, the Secure Enclave will boot the M55-HE core in XIP mode at the base of MRAM. This boot method is called “NTOC” for no-TOC. Many system configurations are assumed to certain defaults since there is no ATOC. It is not recommended to use this mode, even during development. As long as any ATOC is present, then NTOC mode will not be entered even if an application binary is present at the base of MRAM.

A debug stub is used during software development or during production. It is required to power on an M55 core so that you can connect to the core via JTAG. When there is no ATOC present and no application at the base of MRAM, this is the state your MCU should be in when shipped to you from the factory. The Secure Enclave assumes your part is waiting to be provisioned so it boots a “debug stub” to the M55-HE core. At this point you may write an ATOC to NVM using SETOOLs, write an ATOC to NVM using JTAG, or load an application to SRAM for debugging.

In REV_A1 devices, SEROM supports the ability to program an STOC into MRAM if it is blank. To perform this update, you need to use recovery tool. This can only be used when SEROM finds no valid STOC in MRAM.

Maintenance mode is option 1/option 1 of maintenance.exe. This facility allows you to stop the loading of MRAM TOC objects by SES. If you have a “bad” program in the Application TOC it will continue to boot each time RESET occurs, you cannot stop this using ARM- DS. Refer to the Alif Security Toolkit User Guide for instructions on how to use maintenance mode.

Hard maintenance mode is like a safe-mode where no CPU cores are booted except for the Secure Enclave. Using hard maintenance mode will always restore SE UART functionality.

If you have a buggy application that is written to MRAM and you struggle to remove it using normal methods, then using hard maintenance mode will help. This prevents the buggy application from running. Only the Secure Enclave will start, and it will wait for further commands via SE UART. This is also useful for some of the power management examples that will put the Secure Enclave in a low power state meaning the SE UART is not responsive..

Here are the steps for hard maintenance mode:

4. Run maintenance.exe

5. Select 1 – Device Control

6. Select 1 – Hard maintenance mode

7. The response will be Waiting for Target..[RESET Platform]

8. Press the RESET button ONCE or power-cycle the MCU

9. If the handshake is successful, the program will exit to the menu of control functions

10. Press the RETURN button TWICE to exit the maintenance program

11. Run app-gen-toc

12. Run app-write-mram

ISP (In System Programming) is the method of communicating with the Secure Enclave using the SE-UART port and is used by the SETOOLS utilities that program the MRAM. 

In the JSON entry containing your binary, simply add the ’disabled’ flag as follows:

“BLINK-HE”: {

“binary”: “m55_blink_he.bin”,

“version” : “1.0.0”,

“cpu_id”: “M55_HE”,

“loadAddress”: “0x60000000”,

“flags”: [“load”, “boot”]

“disabled”: true

}

An image marked as ‘disabled’ will not appear in your final MRAM image.

A: Deferred is another method, refer to the Secure Toolkit User Guide.  

These can be disabled by adding the ‘signed’ flag to your JSON file:

“BLINK-HE”: {

“binary”: “m55_blink_he.bin”,

“version” : “1.0.0”,

“cpu_id”: “M55_HE”,

“loadAddress”: “0x60000000”,

“flags”: [“load”, “boot”]

“signed”: false

}

Follow the below steps:

1. Run maintenance.exe.
2. Select Option 4 – Utilities
3. Select Option 1 – Terminal mode
4. Press the RESET button.
5. A similar to the below log will appear:

SEROM v0.47.68 0x0000B200

SES B0 v1.97.0 Jun 21 2024 16:41:00
[SES] STOC Part# match ok
[SES] ATOC MISC ok
[SES] System partition address  0x80580000
[SES] STOC DEVICE ok
[SES] ATOC DEVICE ok
[SES] STOC ok
[SES] ATOC ok
[SES] LCS=1
[SES] FC:Rgn
0:2 7:1 8:1 9:1 13:0 13:1 13:2

+———-+——–+————+————+————+————+———-+———–+——–+———-+
|   Name   |  CPU   | Store Addr |  Obj Addr  | Dest Addr  | Boot Addr  |   Size   |  Version  |  Flags | Time (ms)|
+———-+——–+————+————+————+————+———-+———–+——–+———-+
|   DEVICE |  CM0+  | 0x8057FEF0 | 0x8057F4F0 | ———- | ———- |       84 |      0.5.0| u V    |    14.05 |
|   DEVICE |  CM0+  | 0x805C1EC0 | 0x805C14C0 | ———- | ———- |      340 |      0.5.0| u V    |    14.64 |
| * SERAM0 |  CM0+  | ———- | 0x000000C0 | ———- | ———- |    88668 |     1.97.0| —— |     0.00 |
|   SERAM1 |  CM0+  | ———- | 0x00020AC0 | ———- | ———- |    88668 |     1.97.0| —— |     0.00 |
|  A32_APP | A32_0  | 0x8057CCC0 | 0x8057C2C0 | 0x02000000 | 0x02000000 |      644 |      1.0.0| uLVB   |    14.11 |
|   HP_APP | M55-HP | 0x8057D950 | 0x8057CF50 | 0x50000000 | 0x50000000 |     2256 |      1.0.0| uLVB   |    15.01 |
|   HE_APP | M55-HE | 0x8057EC20 | 0x8057E220 | 0x58000000 | 0x58000000 |     2256 |      1.0.0| uLVB   |    14.71 |
+———-+——–+————+————+————+————+———-+———–+——–+———-+
Legend: (u)(C)ompressed,(L)oaded,(V)erified,(s)kipped verification,(B)ooted,(E)ncrypted,(D)eferred

[SES] SE frequency is 100.04 MHz
[SES] os Kernel V10.4.2 (Tickless)
[SES] Main Task – looping forever…

A is a non-SETOOLS generated pseudo-TOC object. It is generated when you program the MRAM with an application through a design/debug tool such as Arm DS + ULINKpro. Please contact Alif’s Applications Team if you need further details.

If you are seeing an ISP_BAD_DEST_ADDRESS error or an ISP_UNKNOWN_COMMAND error when trying to execute a updateSystemPackage command, do the following:

1. First, make sure your board’s SEUART adapter is connected, and that the board is powered up and reset. The LEDs should be blinking.
2. Ensure that there is no terminal program such as TeraTerm running on the SEUART port.
3. Open a command prompt window in the v56 app-release-exec directory.
4. Execute the following command: updateSystemPackage -b 115200 -nr

Your board should update and come back up with the LEDs blinking.

You can verify that the update ran correctly by running maintenance and selecting Option 2 – Device Information” and “Option  2 – Get SES Banner.

You should see the following output:

SES A1 EVALUATION_BOARD SE_FW_0.56.000_DEV v0.56.0 Sep 2 2022 17:44:55

Check you have the correct UART connection for the SE-UART if using multiple ports – use the ‘-d’ option to discover what the host thinks is available

Check your SE-UART RX and TX lines are correctly set. If you see SE-UART output but ISP commands are timing out it means you have the TX line incorrectly set.

If you have a debugger plugged into the JTAG port make sure the power is enabled to the debugger unit.

When you execute the Application MRAM -e app erase option, the tool does not give you any status that it is running – It is running! Just give it a few seconds and it will return to the prompt. If there is a connection problem, you will get the error message and return from the tool.

Only Application TOC MRAM contents.

The SETOOLS are executing from SERAM, so if you erase SERAM there is no longer support for the SETOOLS. If we did implement this, you would only get to run it once!

No. Erasing is not required.

This is caused by the tool not getting a response from the target (Known as “RX=0”). In release V40 this was fixed and now you will get an error that the target is not responding.

You can use SETOOLS running on Linux, Windows, or macOS to access both ALIF and Application MRAM space using serial connection (SE-UART) or JTAG.

Other methods include using development tools like ARM-DS or VS Code, and use JTAG for connection to the device.

For running SETOOLs on other non-native platform (e.g. Raspberry Pi Linux distribution), the SETOOLs python source scripts can be executed via Python 3. Contact your Alif representative to obtain the SETOOLs source scripts.

Yes, but only the application area used for the ATOC. This can be done with option 3/option 1 of maintenance.exe or the -e app option for app-write-mram command. 

The below steps will reset the MCU to factory state. If this doesn’t work, see Hard Maintenance Mode below.

1. Run maintenance.exe

2. Select 3 – MRAM

3. Select 3 – Fast Erase App. Mram (include NTOC)

A common cause of this is that you have the wrong part number / revision. Remember that tools- config.py needs to be run in the app-release directory if you have changed from the default of REV_A1 E7 configuration.

To create and debug an application that will run on one of the M55 cores out of MRAM (eXecute In Place or XIP mode), you should be using the Alif Ensemble CMSIS Device Support pack version 0.2.0 or later.

You need some code running on the Application CPU cores to be able to debug with Arm-DS. We provide the ability to generate an ATOC with debug stubs for all 3 CPU cores for this purpose. Please refer to the Security Toolkit User Guide for details or the Getting Started with Bare Metal Design Using Arm DS user guide for more information.

If you try to debug the M55_HP when the M55_HE is running out of MRAM, or if you only have the M55_HE debug stub running and you get the Unable to connect error in the Arm DS terminal, you should erase the MRAM app area and then load the 3 debug stubs before connecting to the new processor.

If you were debugging an M55_HP design and trying to change to the M55_HE without doing anything, it looks like it connects, but the addresses in the disassembly window are staring at 0x00000000 and not in MRAM. You need to erase the MRAM app area and then load the 3 stubs before connecting to the new processor.

If any debugging of user designs has been done on a particular CPU core, there will be applications resident in the MRAM non-volatile memory that need to be cleared before the debugger can connect to a different CPU core. This can be easily accomplished using 3 SETOOLS commands that utilize pre-built configuration and binary image files.

To do this, open a Windows Command Prompt and go to the top-level directory for the SETOOLS release (c:\app-release is the suggested location). Execute these 3 steps:

Create an ATOC image with 3 SRAM debug stubs for the 3 CPU cores by running:

app-gen-toc.py -f build/config/app-cpu-stubs.json

Erase the entire MRAM memory by running:

app-write-mram.py -e APP

Write the image with 3 debug stubs to MRAM by running:

app-write-mram.py

Calling SERVICES_set_off_cfg() followed by pm_core_enter_deep_sleep_request_subsys_off() is the correct way to enter STOP mode.

This is required from both cores if the application runs on both.

Summary:

• After waking up from STOP mode, the off profile is preserved (the SERAM_MASK is set in the off profile before entering STOP mode), while the run profile is not.
• DTCM/ITCM remain on, and after a cold boot, SRAM0/SRAM1 are enabled by default in the run profile, but this is not the case after waking up from STOP mode.
• SRAM blocks need to be manually re-enabled after waking up from STOP mode.

To ensure that SRAM blocks are enabled after waking up from STOP mode, re-check:

• As you enter STOP mode, the SE apply settings from the off profile, which includes turning off SRAM blocks since they are masked in the that profile.
• Include SRAM1_MASK | SRAM0_MASK in the off profile to prevent it from affecting STOP mode power consumption.
• The power control register for SRAM0/SRAM1 resides in the PD0 Always-On domain, meaning its value is retained through STOP mode, as registers in PD0 are reset only by the POR_N pin.
• If SRAM0/SRAM1 blocks are turned off upon entering STOP mode due to off profile settings, they will remain off upon wake-up. Note that SRAM0/SRAM1 blocks do not support retention, meaning there will be no any additional power consumption during STOP mode.
• If the device fails to exit STOP mode using configured wake-up sources, a reset via the POR_N signal might be necessary.

When using the VSCode IDE, the recommended option is SEGGER J-Link JTAG debugger.

For example, the base model, J-Link BASE Classic, is a popular choice due to its affordability and it is easy to set up and use, making it an excellent choice for both beginners and experienced developers.

Alternatively, you can purchase the Pro and Ultra models (J-Link PRO and J-Link ULTRA+) if you need more advanced functionalities.

Note that you will also need the 19-pin Cortex-M adapter to connect to the boards: 19-Pin Cortex-M Adapter.

Additionally, check the JLink version and make sure that you have the matching firmware in your JLink probe. SEGGER has implemented additional updates for Ensemble in recent releases, so it’s worth to check with a newer version. Tested JLink probes were Version 11.0 (manufactured 03/20) or Version 12.0.

For Arm Development Studio (Arm DS) IDE and Keil MDK, the recommended option is Arm Keil ULINK™ JTAG debuggers.

For IAR Embedded Workbench IDE, the recommended option is IAR I-jet JTAG debuggers.

Many of the power examples run once and leave the chip in STOP mode. The way to get the chip running again is to use hard maintenance to stop the processors and erase the application MRAM.

Here are the steps:
1. Run maintenance.exe
2. Select 1 – Device Control
3. Select 1 – Hard maintenance mode
4. The response will be Waiting for Target..[RESET Platform]
5. Press the RESET button ONCE
6. At that time, the program will exit to the menu of control functions
7. Press RETURN button TWICE to exit the maintenance program
8. Run app-gen-toc
9. Run app-write-mram

These settings determine the behavior of the pins when they are not actively driven (i.e., when the pin is in input mode and not connected to any external signal). The default pull settings ensure that the pins do not float, which could lead to unpredictable behavior due to electromagnetic interference or undefined logic states.

In Alif’s devices, the software user has the flexibility to configure settings such as multiplexing (MUX) number, pull resistors, hysteresis, driver strength, and others as needed before enabling the desired peripheral.

Refer to Section 8.5.3.3.1 Pn_i Register in latest Ensemble E7 HWRM for all specific details.

In general, printing from ISR is discouraged, as it can impact interrupt latencies, lead to potential deadlocks, and degrade system performance.

To address this, Alif’s retarget implementation includes a feature where, if printf() is invoked within an ISR, the trace is buffered instead of being immediately output.

The buffered data is then processed and output when the next printf() is called outside the ISR or when flush_uart() is explicitly invoked.

The code for this can be found here.

There is no restriction on selecting signals from different groups for any of the peripheral IPs. Essentially, if a signal is routed to more than one pin, a suffix (_A, _B, _C, _D, etc.) is added to the signal name to differentiate them.

A group of signals with the same suffix is referred to as a Pin Set. A Pin Set can also serve as an ‘example’ pin configuration. For instance, selecting a particular Pin Set could indicate that the pins are physically located closer together.

Note that routing a single signal to multiple pins is not recommended, such as using signal_A, signal_B, signal_C, etc., simultaneously.

If no boot messages are printed on the SE terminal, ensure you have selected the correct COM port on your PC. Typically, two new COM ports will appear in the list when the board is connected to the host PC. One COM port is designated for SE-UART, and the other is for user UART2/4 print messages.

Additionally, confirm that the correct baud rate is configured in your terminal application. The required baud rate is either 55000 or 57600 bps. Note that in some terminal applications (e.g., TeraTerm), the baud rate may not persist and is getting reset each time the application is restarted. In such cases, you will need to manually reconfigure the serial port settings after restarting the application.

As an additional debugging step, especially for custom boards, you can use an external UART-to-USB adapter. Connect the SEUART_TX pin to the adapter’s input and attach GND. This setup allows you to monitor the SEUART’s TX output. The Secure CPU constantly sends a stream of rotating symbols at 55000 or 57600 bps, indicating it is up and running.

To load a different application, copy your pre-built binary to the <APP release folder>\build\ folder in the SETOOLS directory and modify the app-cfg.json with the new binary name, then run app-gen-toc with the correct JSON file followed by app-write-mram.

If you use Alif’s VSCodeTemplate and check the tasks.json in the .vscode folder, you will find tasks to Prepare/Program and see their functions. Essentially, that’s what needs to be followed.

Optionally, you can configure custom board settings by using the Conductor tool.

To do so, copy the exported SE config .json file from the Conductor to the <APP release folder>\build\config. Rename the file to app-device-config-test.json and reference the file from the ATOC config file.

Then run app-gen-toc and app-write-mram again.

On Alif’s website, navigate to Support > Software & Tools  and find the link Alif SE Host Services API Archive.

Download the zip package, uncompress and look for the files:

APFW0004-se-host-service-release-SE_FW_1.0.87\se-host-service-release\example\power

An intentional software policy is applied, which specifically requires the inclusion of the power domain request to enable the SRAM6 to SRAM9 regions:

runp.power_domains |= PD_SRAM_CTRL_AON_MASK | PD_SRAMS_MASK;

If you request the run profile with memory blocks set only, but don’t enable the associated power domain, the memory blocks will remain powered off.

By setting only the PD_SRAM_CTRL_AON_MASK and PD_SRAMS_MASK masks, all SRAM6 to SRAM9 are powered up. To turn off the memories, clear these masks. This will also clear the memory content.