Base ID clash not detected during build

[jwest115]

F´ Version
Affected Component

---

Problem Description

The following builds successfully when I would have expected an error to be thrown by FPP since the same base ID is used for both spacePacketDeframer and linuxTimer:

 instance spacePacketDeframer: Svc.CCSDS.SpacePacketDeframer base id 0x5000

 instance linuxTimer: Svc.LinuxTimer base id 0x5000

While I do not get an error when building on my machine, I see that CI does fail (in some cases):

Example CI failure (expected): https://github.com/nasa/fprime/actions/runs/15593763502/job/43919047783

Example CI pass (not expected - CI should fail here since the clash is present): https://github.com/nasa/fprime/actions/runs/15591719918/job/43912175806

Context / Environment

Execute fprime-util version-check and share the output.

Operating System: Darwin
CPU Architecture: arm64
Platform: macOS-15.5-arm64-arm-64bit
Python version: 3.9.21
CMake version: 3.24.2
Pip version: 24.3.1
Pip packages:
    fprime-tools==4.0.0a1
    fprime-gds==4.0.0a3
    fprime-fpp-*==3.0.0a11
Project submodules:

Note: @thomas-bc updated the base IDs so they don't collide (see #3726), so I am running with a commit from before the update.

[bocchino]

It looks like LinuxTimer has no events or telemetry, so I think this is expected behavior. The old XML dictionary generator wouldn't have allowed this, but FPP does.

[thomas-bc]

https://nasa.github.io/fpp/fpp-spec.html#Definitions_Component-Instance-Definitions_Semantics

No instance may have a base identifier that lies within the identifier range of another instance.

This appears not to be true then? SpacePacketDeframer would have had a range [5000; 5000 + n], and LinuxTimer had a base ID of 5000

[bocchino]

Item 3.c: "For each instance, this procedure creates a range of identifiers, from the base identifier to the largest identifier associated with the instance. If the component has no identifiers, then this range is empty."

The identifier range is the interval that goes from the smallest to the largest identifier associated with an instance I, including both endpoints. If I has no identifiers, this range is empty. You could say that the identifier range for I contains just the base ID for I in that case, but then you'd be reserving one identifier (the base ID of I) that can never be used by any component instance, since I doesn't use it.

The intent is that if you have a lot of components with no dictionary identifiers, you don't have to reserve a different base ID for each one. This can matter on very small systems.

[bocchino]

You could say that the identifier range for I contains just the base ID for I in that case

This is what the old XML system did, so maybe that's why the behavior is unexpected. It's also not clear to me why one of the CI runs reported an error. Did the linuxTimer have identifiers in that case? If so, there would be a range clash.

[bocchino]

The identifier range is the interval that goes from the smallest to the largest identifier associated with an instance I, including both endpoints.

This assumes that the component-local identifiers start at zero, which is usually the case. If the component-local identifiers don't start at zero, and there are identifiers, the system reserves the identifiers starting from the base ID.

[thomas-bc]

Ok I see your point. I was not expecting that, but it makes sense.

I still feel this phrasing is slightly incorrect though?

No instance may have a base identifier that lies within the identifier range of another instance.

In our case, while LinuxTimer did have an empty range, its base identifier 5000 did collide with the range of SpacePacketDeframer [5000; 5003]
Is what we're trying to convey that two ranges cannot overlap ? Or is there a subtlety I'm missing?

[bocchino]

That's true, according to the wording of the spec that shouldn't be allowed. I will investigate.

[bocchino]

I'm not able to reproduce this behavior. On the head of devel, when I modify the instances spacePacketDeframer and linuxTimer so they have the same base ID, I see the expected error.

While I do not get an error when building on my machine

@jwest115 Can you point us to a branch that exhibits this behavior?

[bocchino]

OK, it looks like I can reproduce the behavior by making the base IDs the same and swapping the order of the instances. I'll open an issue in the FPP repo.

[bocchino]

Here is the FPP issue: nasa/fpp#741. I think you can close this one as a duplicate.

[jwest115]

Thanks!