Fix issue #111: AM26x academy examples fail to build with MCU+ SDK 11.x#143
Fix issue #111: AM26x academy examples fail to build with MCU+ SDK 11.x#143pratheesh wants to merge 8 commits into
Conversation
…with MCU+ SDK 11.x
MCU+ SDK 11.0/11.1 split the drivers and board libraries by OS variant,
so the link step must reference the OS-qualified archives and the build
must define OS_FREERTOS. The am243x/am64x academy examples were already
updated; the am261x, am263x and am263px FreeRTOS examples were not, so
they fail to link against SDK 11.x (and v2025.00.00).
Bring all remaining r5f FreeRTOS academy examples in line with the
am243x reference:
- makefile: drivers/board libs -> *.ti-arm-clang.freertos.${ConfigName}.lib
(LIBS_common and LIBS_NAME)
- example.projectspec: add -DOS_FREERTOS alongside -DSOC_*
Applied uniformly across getting_started_labs (assembly_code, c_code,
c_and_assembly, c_and_inline_assembly), gpio/gpio_toggle and intc/intc_mcu
for am261x-lp, am261x-som, am263x-lp, am263x-cc, am263px-lp, am263px-cc
(64 files: 32 makefiles + 32 projectspecs). nortos examples are unaffected.
Closes TexasInstruments#111.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Code Review by Qodo
Context used 1. CI tests only SDK 11.1
|
PR Summary by QodoFix AM26x FreeRTOS example builds for MCU+ SDK 11.x (OS-qualified libs + OS_FREERTOS) WalkthroughsDescription• Switch AM26x FreeRTOS examples to SDK 11.x OS-qualified drivers/board archives. • Define OS_FREERTOS consistently for both Makefile and CCS builds. • Update bootimage generation targets to use MulticoreELF (*.mcelf) flow. • Move CI workflows for AM26x devices to MCU+ SDK 11.01.00.19. Diagramgraph TD
A["GitHub Actions"] --> B["Makefile / projectspec"] --> C["Compiler & Linker"] --> D{{"MCU+ SDK 11.x"}} --> E["Output: .out / .mcelf"]
B --> F["Bootimage gen"] --> E
High-Level AssessmentThe following are alternative approaches to this PR: 1. Centralize OS-qualified lib naming in shared include .mak
2. Derive OS variant from `OS` variable instead of explicit `OS_FREERTOS`
Recommendation: The PR’s approach (mirror the known-good AM243x FreeRTOS pattern) is the safest, lowest-risk fix for SDK 11.x compatibility. Consider a follow-up to centralize library naming/defines to reduce future repetitive updates, but keeping this PR mechanical is appropriate for a build-break fix. File ChangesBug fix (132)
|
|
Review empty example from MCU+ SDK 10.2 vs 11.x, compare all relevant files and apply any missing changes to OpenPRU examples |
…S_common Qodo review on PR TexasInstruments#143 correctly flagged that the AM26x FreeRTOS makefiles linked the OS-qualified drivers.*.freertos.* / board.*.freertos.* archives and added -DOS_FREERTOS to the CCS projectspecs, but omitted -DOS_FREERTOS from DEFINES_common in the makefiles (the AM243x FreeRTOS reference defines it in both). That left a make-vs-CCS configuration mismatch. Add -DOS_FREERTOS to DEFINES_common in all 32 AM26x r5f FreeRTOS academy makefiles so the make and CCS builds agree on the OS configuration. NOTE: this PR remains WIP/draft. Per issue TexasInstruments#111, AM26x MCU+ SDK 11.0/11.1 uses a different makefile structure than AM243x/AM64x SDK 11.1/11.2, so the full port (CI SDK-version bump to 11.x for AM26x + OptiShare relink infra, matching PR TexasInstruments#110 but adapted for AM26x) still needs to be done and verified against the AM26x SDK 11.x before this can build green. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Looking for bugs?Check back in a few minutes. An AI review agent is analyzing this pull request. |
|
Thanks for the review. Status update + converting this to draft. Addressed (commit Marking draft — this is not yet complete. Per the actions in #111, AM26x MCU+ SDK 11.0/11.1 uses a different makefile structure than AM243x/AM64x SDK 11.1/11.2, so the AM243x infra changes can't simply be mirrored (as @nsaulnier-ti noted). The remaining work, validated against the AM26x SDK 11.x, is:
I'll complete and verify that against the AM26x SDK 11.x and then move this out of draft. |
The AM26x academy R5F examples now link the SDK-11.x OS-qualified drivers/board archives, but CI still installed MCU+ SDK 10.02 for am261x/am263px/am263x, where those archives don't exist -- so the Build (am26x) jobs failed with: No rule to make target 'drivers.am261x.r5f.ti-arm-clang.freertos.release.lib' Bump the am261x, am263px and am263x matrix entries (both makefile.yml and ccs_build.yml) from SDK 10.02.x to 11.01.00.19, the coordinated 2025-12 AM26x MCU+ SDK 11.1 release (installer URLs verified, HTTP 200). The am263px 11.x lib layout was confirmed locally: the SDK ships drivers.am263px.r5f.ti-arm-clang.freertos.<cfg>.lib, matching the example makefile changes. am243x/am64x already build against SDK 11.02. Part of TexasInstruments#111. Still WIP/draft pending green CI on the bumped SDK. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
…U+ SDK 11.x Under SDK 11.x the kernel/dpl headers (ClockP.h, SemaphoreP.h, ...) hard #error unless an OS is defined, so every R5F example that pulls them in must build with -DOS_FREERTOS / -DOS_NORTOS. The earlier commits only updated the academy/ FreeRTOS examples; the examples/ tree (empty and empty_c, all 6 AM26x boards) was still on the old un-qualified libs with no OS define, so the SDK-11.x am26x CI build failed with: ClockP.h:89:2: error: "Define OS_NORTOS, OS_FREERTOS or OS_SAFERTOS" Apply the same FreeRTOS treatment to the 12 examples/ AM26x r5f makefiles + projectspecs: OS-qualified drivers/board libs (*.freertos.*) and -DOS_FREERTOS in DEFINES_common and the CCS projectspec. All 44 AM26x r5f ti-arm-clang examples (academy + examples) are FreeRTOS; there are no nortos r5f am26x examples to update. Part of TexasInstruments#111 (WIP/draft until CI is green). Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
…1.00.19 has no elf2rprc.js) The per-device MCU+ SDK 11.01.00.19 installers for am261x/am263x/am263px do not ship the legacy RPRC/appimage tool tools/boot/out2rprc/elf2rprc.js, so the .appimage recipe died at $(OUTRPRC_CMD) with MODULE_NOT_FOUND (makefile:309). These SoCs use the MulticoreELF (.mcelf) boot format, and the example makefiles already carried a complete genimage.py recipe (MCELF_* vars come from the SDK's devconfig.mak). Default TARGETS to $(BOOTIMAGE_NAME_MCELF) and drop the dead RPRC/appimage/XIP path (elf2rprc.js, xipGen, multicoreImageGen) across the AM26x R5F examples. HS signing now targets the .mcelf image. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
|
Code review by qodo was updated up to the latest commit 6546ede |
![qodo-code-review[bot]](https://avatars.githubusercontent.com/in/484649?s=60&v=4){kind=small}
| - device: am261x | ||
| mcu_plus_sdk: mcu_plus_sdk_am261x_10_02_00_15 | ||
| sdk_installer: mcu_plus_sdk_am261x_10_02_00_15-linux-x64-installer.run | ||
| sdk_url: https://dr-download.ti.com/software-development/software-development-kit-sdk/MD-h64OlWnQrg/10.02.00.15/mcu_plus_sdk_am261x_10_02_00_15-linux-x64-installer.run | ||
| mcu_plus_sdk: mcu_plus_sdk_am261x_11_01_00_19 | ||
| sdk_installer: mcu_plus_sdk_am261x_11_01_00_19-linux-x64-installer.run | ||
| sdk_url: https://dr-download.ti.com/software-development/software-development-kit-sdk/MD-h64OlWnQrg/11.01.00.19/mcu_plus_sdk_am261x_11_01_00_19-linux-x64-installer.run | ||
| - device: am263px | ||
| mcu_plus_sdk: mcu_plus_sdk_am263px_10_02_00_15 | ||
| sdk_installer: mcu_plus_sdk_am263px_10_02_00_15-linux-x64-installer.run | ||
| sdk_url: https://dr-download.ti.com/software-development/software-development-kit-sdk/MD-JVtW1V4WfA/10.02.00.15/mcu_plus_sdk_am263px_10_02_00_15-linux-x64-installer.run | ||
| mcu_plus_sdk: mcu_plus_sdk_am263px_11_01_00_19 | ||
| sdk_installer: mcu_plus_sdk_am263px_11_01_00_19-linux-x64-installer.run | ||
| sdk_url: https://dr-download.ti.com/software-development/software-development-kit-sdk/MD-JVtW1V4WfA/11.01.00.19/mcu_plus_sdk_am263px_11_01_00_19-linux-x64-installer.run | ||
| - device: am263x | ||
| mcu_plus_sdk: mcu_plus_sdk_am263x_10_02_00_13 | ||
| sdk_installer: mcu_plus_sdk_am263x_10_02_00_13-linux-x64-installer.run | ||
| sdk_url: https://dr-download.ti.com/software-development/software-development-kit-sdk/MD-r5FY9rRaGv/10.02.00.13/mcu_plus_sdk_am263x_10_02_00_13-linux-x64-installer.run | ||
| mcu_plus_sdk: mcu_plus_sdk_am263x_11_01_00_19 | ||
| sdk_installer: mcu_plus_sdk_am263x_11_01_00_19-linux-x64-installer.run | ||
| sdk_url: https://dr-download.ti.com/software-development/software-development-kit-sdk/MD-r5FY9rRaGv/11.01.00.19/mcu_plus_sdk_am263x_11_01_00_19-linux-x64-installer.run |
There was a problem hiding this comment.
1. Ci tests only sdk 11.1 📎 Requirement gap ☼ Reliability
The CI matrix for AM26x devices is pinned to MCU+ SDK 11_01_00_19 only, so there is no build verification coverage for SDK 11.0 as required. This fails the requirement to verify and record build status for both SDK 11.0 and 11.1 across AM261x/AM263x/AM263Px.
Agent Prompt
## Issue description
The compliance checklist requires build verification for AM261x/AM263x/AM263Px on MCU+ SDK 11.0 and 11.1, but the CI matrices only include SDK 11.1 (`11_01_00_19`).
## Issue Context
Current CI coverage does not demonstrate (or record) SDK 11.0 build status for AM26x, which is explicitly required.
## Fix Focus Areas
- .github/workflows/makefile.yml[30-41]
- .github/workflows/ccs_build.yml[163-174]
ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools
| " | ||
| linkerBuildOptions=" | ||
| -lfreertos.am261x.r5f.ti-arm-clang.release.lib | ||
| -ldrivers.am261x.r5f.ti-arm-clang.release.lib | ||
| -lboard.am261x.r5f.ti-arm-clang.release.lib | ||
| -ldrivers.am261x.r5f.ti-arm-clang.freertos.release.lib | ||
| -lboard.am261x.r5f.ti-arm-clang.freertos.release.lib | ||
| -llibc.a |
There was a problem hiding this comment.
2. Debug libs still unqualified 🐞 Bug ≡ Correctness
AM26x FreeRTOS example.projectspec files update Release to link drivers.*.freertos.*/board.*.freertos.* archives, but Debug still links the old unqualified drivers.*.debug.lib/board.*.debug.lib. When building against MCU+ SDK 11.x (where the OS-qualified naming is required, as already assumed by Release), CCS Debug builds will fail to resolve these libraries or link the wrong variants.
Agent Prompt
## Issue description
AM26x FreeRTOS CCS project specs were only partially updated: Release links OS-qualified `drivers.<soc>...freertos...` and `board.<soc>...freertos...` archives, but Debug still links the pre-SDK-11 unqualified archives.
## Issue Context
The AM243x FreeRTOS projectspec shows that *both* Debug and Release should use `*.freertos.<config>.lib` for `drivers` and `board`.
## Fix
For **all AM26x FreeRTOS** `ti-arm-clang/example.projectspec` files updated in this PR, change the **Debug** `linkerBuildOptions` entries:
- `-ldrivers.<soc>.r5f.ti-arm-clang.debug.lib` -> `-ldrivers.<soc>.r5f.ti-arm-clang.freertos.debug.lib`
- `-lboard.<soc>.r5f.ti-arm-clang.debug.lib` -> `-lboard.<soc>.r5f.ti-arm-clang.freertos.debug.lib`
(Leave `-lfreertos...debug.lib` as-is unless the SDK also OS-qualifies it.)
## Fix Focus Areas
- academy/getting_started_labs/assembly_code/solution/mcuplus/am261x-lp/r5fss0-0_freertos/ti-arm-clang/example.projectspec[79-90]
- academy/getting_started_labs/assembly_code/solution/mcuplus/am263x-lp/r5fss0-0_freertos/ti-arm-clang/example.projectspec[79-90]
- academy/getting_started_labs/assembly_code/solution/mcuplus/am263px-lp/r5fss0-0_freertos/ti-arm-clang/example.projectspec[79-90]
- examples/empty/mcuplus/am261x-lp/r5fss0-0_freertos/ti-arm-clang/example.projectspec[79-90]
ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools
There was a problem hiding this comment.
this is valid, need to do the same for Debug mode for the libs naming in all examples
Qodo reviews are paused for this user.Troubleshooting steps vary by plan Learn more → On a Teams plan? Using GitHub Enterprise Server, GitLab Self-Managed, or Bitbucket Data Center? |
Mirror the SDK 11 library naming fix to the Debug configuration of all AM26x FreeRTOS example.projectspec files, matching what was already done for Release. drivers/board archives are now OS-qualified (drivers.<soc>.r5f.ti-arm-clang.freertos.debug.lib) in both Debug and Release, per reviewer feedback. freertos.<soc>...debug.lib is left as-is. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
|
@a1248924 thanks — addressed in 3692252. Applied the same FreeRTOS lib naming to Debug mode across all AM26x FreeRTOS
|
3 participants
Closes #111.
Problem
MCU+ SDK 11.0/11.1 split the
driversandboardlibraries by OS variant, so the archive names are now OS-qualified (e.g.drivers.<soc>.r5f.ti-arm-clang.freertos.${ConfigName}.lib) and the build must defineOS_FREERTOS. Theam243x/am64xacademy examples were already updated to the new convention, but the am261x, am263x and am263px FreeRTOS examples still reference the old un-qualified archives, so they fail to link against SDK 11.x (andv2025.00.00).Fix
Bring all remaining r5f FreeRTOS academy examples in line with the existing
am243xreference:drivers/boardlibs →*.ti-arm-clang.freertos.${ConfigName}.libin bothLIBS_commonandLIBS_NAME-DOS_FREERTOSalongside the-DSOC_*defineApplied uniformly across:
getting_started_labs(assembly_code, c_code, c_and_assembly, c_and_inline_assembly)gpio/gpio_toggleintc/intc_mcufor
am261x-lp,am261x-som,am263x-lp,am263x-cc,am263px-lp,am263px-cc.64 files changed (32 makefiles + 32 projectspecs).
nortosexamples are unaffected.Notes / verification
am243x-evmFreeRTOS examples line-for-line.