-
Notifications
You must be signed in to change notification settings - Fork 153
Description
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
0x00000000-0x00040000"Program / code flash" (pack contains .FLM, usable with pyocd)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.yamlto 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?