There is a docs directory with a doxyfile. This can be built but output is ignored as part of this repo. Where to host the output? If not hosted, then update current readme to alert contributors of needing doxygen to build docs or just read the template (example) project.

Is there a way to READ external flash?

Currently GCC linker file doesnt create output that is compatible with armcc tools. The c_blob and py_blobs rely on armcc output formats. For GCC support the following is needed:

1. makefile in pgen extended to support post build user commands
2. *.ld modified to mimic the same memory layout as *.sct
3. possible update to scripts/generate_blobs.py if gcc output and keywords are not the same as armcc.

Is there a flash algorithm available for F401/F091? Where did the algorithm for F411 come from?

@MarceloSalazar

Building all projects is with pgen.

>pgen build -f records/projects.yaml -t uvision

There should be a script that takes all the c_blobs and py_blobs and moves them to a release folder which is versioned as part of this repo.

A new Verify field has been added to DAPLinks program_target_t structure. This should be included in the flash_blob files generated for use inside DAPLink.

Generating and building uvision projects also creates the .c and .py files with the blobs embedded, but this does not happen with make_gcc_arm.

I don't have IAR, so I cannot confirm if these files are generated with that project type or not.

The blobs are used in c programs and python scripts. The routines are also relevant for bootloaders and applications requiring in-application-programming functionality. Additional output should be created from each project.

Hello. I am trying to run a flash_algo.py file.
I need to create an algo file for stm32h7. However, I am getting the error.
What could be the reason for this?

(venv) root@Note:/mnt/d/pyTest# python3 flash_algo.py STM32H7xx.FLM c_blob.tmpl out.c
Traceback (most recent call last):
  File "flash_algo.py", line 349, in <module>
    main()
  File "flash_algo.py", line 45, in main
    algo.process_template(args.template, args.output)
  File "flash_algo.py", line 158, in process_template
    target_text = template.render(data_dict)
  File "/mnt/d/pyTest/venv/lib/python3.8/site-packages/jinja2/environment.py", line 1304, in render
    self.environment.handle_exception()
  File "/mnt/d/pyTest/venv/lib/python3.8/site-packages/jinja2/environment.py", line 925, in handle_exception
    raise rewrite_traceback_stack(source=source)
  File "<template>", line 41, in top-level template code
jinja2.exceptions.UndefinedError: 'header_size' is undefined

The project generator has been updated to include support for Cortex-M33 targets. The uvision project template files need to be updated for ARM compiler 6 projects. The current template causes for following build error:

ArmClang.exe: error: unsupported option '--gnu', did you mean '-fgnu'?

I've attempted to write interface firmware for a new mbed platform. The interface processor is a MK20DX128VFM and the target processor is a STM32L151CC. I've linked to my DAPLink and FlashAlgo repositories.

Currently the drag-n-drop program of the device appears successful. After programming is finished there is no fail.txt file in the USB drive. The target processor does not appear to execute, however. When connecting with a debugger, I see the following message each time I try to continue/run the application:

(gdb) c
Continuing.
stm32l1.cpu -- clearing lockup after double fault

However, if I load the same binary using the debugger or an external programmer (bypassing the interface processor), the device functions perfectly. This fact leads me to believe that the issue is the flash algorithm itself or the state the processor is in after the flash algorithm runs.

The flash algorithm code was taken from an example flash algorithm included with uVision and updated. The original code can be found at C:\Keil_v5\ARM\Flash\STM32L15x.

I have read out the contents of flash via the debugger and it looks the same (MD5 checksums matched) as the original binary.

I am aware that a double fault is usually caused by an invalid vector table, but as far as I can tell the vector table in the application is fine.

I've attached the test binary I've been using. When programmed with the debugger or an external programmer, it works great. When programmed by the interface firmware & flash algorithm, it doesn't work at all. I added the .txt to the binary name so GitHub would let me attach it.

I appreciate any help or advice on this issue.
blink.bin.txt

My env:

Python 2.7.12
progen 0.9.2
Keil MDK 5.17
ARM Compiler 5.06 update 1 (build 61)

As the README.md says, execute cmd:

$ progen generate -t uvision

then open project projectfiles\uvision\lpc4088\lpc4088.uvproj, try to build the target, log shows:

Build target 'lpc4088'

then MDK UV4.EXE collapses.

anything wrong?

The DevDscr has details about the target and could be extended to have information about where the algo is placed in RAM (start, buffer, SP,etc..) These are currently hardcoded in the generate script and also the templates. Should be dynamically generated by the flash algo projects being they're aware of the target on which they run

There is no support for FTMRE flash module. Could you please either add the support or add the flash blob file for the mentioned MCU's? Thank you.

Background

I have a Keil pack that is missing a flash memory region which I'd like to manipulate via pyocd.

Pack

https://developer.arm.com/embedded/cmsis/cmsis-packs/devices/NXP/S32K142UAxxxLLx
Keil.S32_SDK_DFP.1.5.0.pack
Keil.S32_SDK_DFP.pdsc

Memory regions

1. 0x00000000-0x00040000 "Program / code flash" (pack contains .FLM, usable with pyocd)
2. 0x10000000-0x1000FFFF "FlexNVM / code flash" (no .FLM)

relevant section of .pdsc:

        <!-- ******************************  Device 'S32K142'  ****************************** -->
        <device Dname="S32K142">
          <book name="doc/S32SDK_S32K142_UserManual.pdf" title="S32SDK User Manual"/>

          <compile header="platform/devices/device_registers.h"/> <!-- generates warning in PackCheck because name is not CMSIS conform -->
          <compile define="CPU_S32K142"/>
          <debug  svd="platform/devices/S32K142/S32K142.svd"/>
          <memory id="IROM1"                                     start="0x00000000" size="0x00040000" default="1" startup="1"/>
          <algorithm name="CMSIS/Flash/S32K142_P256_2KB_SEC.FLM" start="0x00000000" size="0x00040000" default="1"/>
        <!-- variants... -->
        </device>

Problem encountered

I've found and read the CMSIS-Pack-Spec Flash Algorithm documentation: https://open-cmsis-pack.github.io/Open-CMSIS-Pack-Spec/main/html/flashAlgorithm.html

I've started by reproducing the existing .FLM for memory region 0x0000000-0x00040000. A patch is here:
driftregion@c646334

Using this patch to pyocd flash ... , I find the following error:

pyocd.target.pack.flash_algo.FlashAlgoException: RW section does not follow RO section

This looks linker-related, but I'm not sure where to start.

I've attached the original .FLM (S32K142_P256_2KB_SEC.FLM.bak) and the .FLM produced by my patch (S32K142_P256_2KB_SEC.FLM) as a zip file:
S32K142_P256_2KB_SEC.zip

FlashAlgo:project_generator question

• is it possible for a project in projects.yaml to output multiple .elf/.FLM files? This target device has two non-contiguous flash regions. If I understand correctly, each region needs its own .FLM

Upstreaming question

• If this works and results in a usable .FLM, is there an established way to share community-extended .pack files?
• Alternately (preferably?), is it probable that NXP would update their .pack?

Related:
pyocd/cmsis-pack-manager#122 (comment)

This isn't documented at all

use gnu toolchain,no section name PrgData in output file *.elf