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

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.  

STOC is the ALIF contents of MRAM. It contains the SERAM images, DEVICE configuration such as Firewalls. ATOC is MRAM used by the Application cores.

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.

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

}

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].

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.