The License File Could Not Be Found. Check That Armlmd_license_file Is Set Correctly

[Leda Billock]

Building project DAPLink (k20dx_frdmkl02z_if, ARM)Scan: DAPLinkCompile [1.3%]: frdmkl02z.c[ERROR] Error: C9555E: Failed to check out a license.The license file could not be found. Check that ARMLMD_LICENSE_FILE is set correctly.ARMLMD_LICENSE_FILE is not set. You must set this to the path to your license.Information about this error is available at: licensing information is available at: "

Though I am not personally familiar with this project, I see it uses the Arm Compilers, which are indeed license managed.

Have you installed Arm Development Studio? If you go to Help > Arm License Manager within the IDE, you can generate an evaluation license which should allow you to proceed.

-and-software/embedded/arm-development-studio/downloads

Using the documents: UM10430 (LPC1857 reference manual), Cortex: tm: -M3 - Technical Reference Manual and CoreSight: tm: Components - Technical Reference Manual (where you have the information about the SWD), I tried to understand the values obtained in the sniffer, but I couldn't find the following addresses in any of these documents:

0xE000EFBC: - The register 0xE000EFBC is outside the address range shown in chapter 8, as the ranges are: - 0xE000EF00 - 0xE000EF0F. Software Trigger Exception Register - 0xE000EFD0 - 0xE000EFFF. ID space.

- As I understand it, to add a new microcontroller in the code it is necessary to generate a BLOB according to the file "DAPLink / docs / PORT_TARGET_FAMILY.md". This file references the project " " to generate the BLOB.

Within this repository "FlashAlgo" has two python projects, "flash_algo.py and generate_blobs.py".

I have some doubts:

- How should I use these softwares, flash_algo and generate_blobs?

- In the generete_blobs software, I need to pass two arguments: elf_pach and blob_start. What should be the content of these arguments?

- In the flash_algo software, I need to pass two arguments: input and template. What should be the content of these arguments?

There are already flash algorithms for NXP using IAP (which is the only way to program the flash) in the NXP directory. It works generically and you just add a new entry in a table for your part. There is one for LPC4337 which is virtually identical to your part, so just modify that.

To be able to change what you told us, I need to understand the questions I asked in the previous question, because I need to generate the BLOB of LPC1857 and I cannot use the BLOB of LPC4337 and for that, I need to use the Flash Algo algorithm. Can you help me generate this BLOB for LPC1857, please?

I am at a point in my project that needs a lot of help. I realized that you liked my answer, I would like to know if you are elaborating the answer. Do not understand it as a demand from me, but I really need that help.

My main question is what would be the sequence of manipulations of the CORTEX registers for the firmware located in RAM to be executed. In other words, once my firmware is loaded in RAM, what should I do to make it run?

The answer is quite complex. after we load the algorithm into RAM, the SWD host will modify PC to RAM address and write some core register to let target MCU runing that code. The detail implementation can be found on ARM's DAPLINK source. A colleague wrote a AN about this long time ago, you can refer to it:

However, I am now having trouble recording the LPC1857. I added the files flash_blob.c, target.c and in the compilation files (.yaml) of the project I put the microcontroller. So far everything is ok. I successfully built the project, I managed to put it in the BOARD that would record the LPC1857, however, when I drag and drop the firmware I would like to record, the following error message appears:

It is worth remembering that when I delete any of the parts added to the flash I can perform the recording of the other flash, for example, when I delete all parameters of the flash 0x1A000000, I can write a firmware in the 0x1B000000. But when I try to record a firmware that uses both flashes, the following error appears:

For Verify, we need to check if Verify is implemented in the flash algorithm. Some flash algorithm does not implement this function, so 0x0000_0000 just like DAPLINK think Verify function address is illegal and pass this function.

About DAP-Link, I started an analysis and stopped at the point of generating the BLOB, where I checked the documentation that needed to use Flash_Algo ( ), but I couldn't understand how to use this software to generate the BLOB. This did not concern me, because I am at a very advanced level of my project. Today with my project I can program via SWD microcontrollers like: STM32F107 from ST, SAMD and SAM4E from Atmel.

The boot action is used to cause the device to boot using the deployedfiles. Depending on the parameters in the job definition, this could be byexecuting a command on the dispatcher (for example/usr/bin/qemu-system-x86_64) or by connecting to the device over serial orssh. Depending on the power state of the device and the device configuration,the device may be powered up or reset to provoke the boot.

Boot actions which result in a POSIX type login or shell must specify a list ofexpected prompts which will be matched against the output to determine theendpoint of the boot process. There are no default prompts, the test writer isresponsible for providing a list of all possible prompts.

Some systems require the test job to specify a username and optionally apassword to login. These values must be specified in the test job submission.If the system boots directly to a prompt without needing a login, theauto_login details can be omitted from the test job submission.

The prompt to match when the system requires a login. This prompt needs to beunique across the entire boot sequence, so typically includes : and shouldbe quoted. If the hostname of the device is included in the prompt, this can beincluded in the login_prompt:

After login (or directly from boot if no login is required), LAVA needs tomatch the first prompt offered by the booted system. The full list of possibleprompts must be specified by the test writer in the test job submission.

Each prompt needs to be unique across the entire boot sequence, so typicallyincludes : and needs to be quoted. If the hostname of the device isincluded in the prompt, this can be included in the prompt:

One of the key definitions in the device type template foreach device is the list(s) of boot commands that the deviceneeds. These are sets of specific commands that will be run to bootthe device to start a test. The definitions will typically includeplaceholders which LAVA will substitute with dynamic data asnecessary. For example, the full path to a tftp kernel image will beexpanded to include a job-specific temporary directory when a job isstarted.

In some cases, the boot commands list in the template maynot provide all of the commands used; lines will also begenerated from other data in the template. For example: the commandsetenv kernel_addr_r '0x82000000' might be generated from theload addresses which match the type of kernel being deployed.

When a test is started, the appropriate list of commands will beselected. LAVA then substitutes the placeholders in the list togenerate a complete command list. The final parsed and expanded bootcommands used for a test are reported in the logs for that test job,e.g.:

During testing and development, it can sometimes be useful to usea different set of boot commands instead of what is listed in thejinja2 template for the device-type. This allows test writers tochange boot commands beyond the scope of existing overrides. To worksensibly in the LAVA environment, these commands will still need toinclude the placeholders such that temporary paths etc. can besubstituted in when the test job is started.

In this example (for an x86 test machine using iPXE), the commandschange the root argument to the kernel to boot from a SATA drivewhich has been configured separately. (For example, by the admins orby test writers from a hacking session.)

If the commands are to be used regularly, ask on the lava-users mailinglist requestingthat a label is created in the templates for this set of commands.Alternatively, you can request a new override to make the existing labelsmore flexible. You can also propose a patch yourself.

Some devices deploy the boot commands inside the boot image which isthen deployed using fastboot. To boot the device after deployment,LAVA does not interrupt the bootloader (e.g. U-Boot or Grub) and letsthe configured boot arguments control the boot.

In some situations, a test kernel can fail and cause the device toreset to the bootloader. The presence of configured boot commands leadsto the device booting into an environment which is not necessarily theone required by the test writer and the failure of the test kernel canthen be hidden. To handle this issue, a failure_message can bespecified to match a string output by the bootloader after the devicehas reset. The test job will then fail after the reset and tracking thekernel errors.

The bootargs dictionary allows you to override the default Kernel bootargsprovided by the AVH model. The normal key is used for every regular boot.The restore key, if present, is used for a first boot prior to the devicebeing declared ready. It is expected that the device will reboot itself toindicate that this phase is complete. It is used, for example, on the RaspberryPi 4 to expand the root FS.

The depthcharge boot method takes no arguments or parameters. It is usedto boot the downloaded kernel image, and optionally a device tree and aramdisk. The files are converted into an FIT (U-Boot Flattened Image Treeformat) image suitable to be booted by Coreboot using the Depthcharge payload,typically used by Chrome OS devices. It also creates a separate text file withthe kernel command line which is made available to the DUT over TFTPalongside the FIT image.

3a8082e126