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 (See Tools User Guide on how to achieve this).

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!)

Go to the Alif’s website Support > Software & Tools > Ensemble Software & Tools and find the link under Alif SE Host Services API Archive (Gen 2).

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

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 

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 [click here] 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 RETURN 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 [click here].  

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

}

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.

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.

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)”

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. 

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.

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 Applications if you want details.

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

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 executables for Windows (x86_64), Linux (amd64), and macOS (Apple “M”).

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

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.

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

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.

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. [version 0.2.0 link here]

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, you get this error from Arm DS:

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

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.