[Specification] Dependency of `<flashinfo>` section on `flash debug sequences` is missing in the specification

[jkrech]

Documentation of FlashInfo does not mention that Flash Debug Sequences are a pre-requisite for flash programming without using RAM on the target to be usable. These sequences have pre-defined names but no default implementation. Therefore they must be described for a device.

I assume that these functions need to be implemented similar to FLM projects: https://open-cmsis-pack.github.io/Open-CMSIS-Pack-Spec/main/html/algorithmFunc.html

Relates to Open-CMSIS-Pack/vscode-cmsis-debugger#1009

[tarek-bochkati]

Hello @jkrech

My understanding of the current specification is the following.

First, the presence of flashinfo should not mean that a defined flash programming algorithm (flashloader) has to be ignored. If a flash algorithm is explicitly provided, a tool such as pyOCD should normally use it, since that is usually the intended path and also the more efficient one.
Only if the algorithm cannot be used (for example because the required RAM is not available) should the tool fall back to programming based only on flashinfo, unless the user explicitly chooses that behavior.

Second, the presence of flashinfo should not automatically imply that the related debug sequences must also be provided. Adding such a requirement to the PDSC specification would effectively introduce a breaking change for existing packs.

So overall, I think we should be careful here from a backward-compatibility point of view. Making something mandatory that was not mandatory before is generally not backward compatible, while relaxing an existing requirement usually is.

[jreineckearm]

@tarek-bochkati , Open-CMSIS-Pack/vscode-cmsis-debugger#1009 deals with the flaw in pyOCD which will go away. flashinfo should be simply ignored if no related sequences are there. If at all, a warning needs to be issued by packchk and/or the executing tools.

Aim of this spec update is to be clearer in wording that flashinfo is ignored if no sequences are present. We had situations in the past where pack implementers thought this element could be used to override flash device infos baked into the FLM. This is not its intention.

We are working at the same time on a mechanism to support both FLM and flash sequences and make them selectable at runtime depending on for example the device state. See Open-CMSIS-Pack/vscode-cmsis-debugger#1013. I expect more changes in that are of the spec then.

Would you mind if we include you in the review once we have a draft (or two, depending on how we decide to implement the spec change)?

[tarek-bochkati]

@jreineckearm yes, please count me in for the review.

From my side, the behavior I would expect is roughly this:

If an algorithm is defined

• programming should default to using that algorithm
• debug sequences should only be used if the user explicitly chooses that path
• if flashinfo is present without the related debug sequences, that should still be accepted without warning or error as long as the algorithm is available and being used

Only if the algorithm is missing, or the user explicitly disables it, should the tool evaluate whether flashinfo and sequences are sufficient for programming.

In that fallback case, I would expect something like this:

algorithm	flashinfo	sequences	result when programming device memory
1	0	0	use algorithm
1	0	1	use algorithm
1	1	0	use algorithm, no warning/error
1	1	1	use algorithm by default, unless the user selects debug sequences
0	0	0	error: cannot program
0	0	1	error: missing memory sectorization
0	1	0	error: missing debug sequences
0	1	1	use the defined debug sequences

So in short, flashinfo without sequences should not be considered an issue by itself when an algorithm is available, since the algorithm is still the valid programming path. It only becomes an error case if the algorithm is unavailable or explicitly disabled and the tool then needs to rely on the sequence-based path.

I also agree that clearer wording in the spec would help, especially to avoid the impression that flashinfo is meant to override the device information already embedded in the FLM.