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
Code Review by Qodo
Context used 1. Long sdk_url lines (makefile.yml)
|
PR Summary by QodoFix AM26x FreeRTOS academy/examples build with MCU+ SDK 11.x
AI Description
Diagram
High-Level Assessment
Files changed (134)
|
|
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. |
|
Code review by qodo was updated up to the latest commit 6546ede |
| - 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? |
|
@a1248924 thanks — addressed in 3692252. Applied the same FreeRTOS lib naming to Debug mode across all AM26x FreeRTOS
|
|
AM261x fails the makefile build for all SDKs. Error looks like this: (where 1 is simply the name of the test directory I mirrored this PR to):
|
…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>
…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>
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>
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>
3692252 to
c037f86
Compare
| 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. Long sdk_url lines (makefile.yml) 📘 Rule violation ⚙ Maintainability
The workflows add sdk_url lines that exceed the hard 129-character repository line-length limit, reducing readability and creating avoidable formatting noncompliance in CI configuration. This violates the stated line-length constraint for hand-written config files.
Agent Prompt
## Issue description
The workflow files contain newly-added/updated `sdk_url` entries whose unwrapped URL values exceed the repository’s hard 129 character line-length limit.
## Issue Context
The repository enforces a hard 129-char limit for hand-written source/config files; these long URLs can be wrapped using YAML folded/scalar syntax (for example `sdk_url: >-` with the URL on the next indented line) or refactored by introducing a shared base URL variable.
## Fix Focus Areas
- .github/workflows/makefile.yml[33-41]
- .github/workflows/ccs_build.yml[166-174]
ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools
| $(RM) $(BOOTIMAGE_NAME) | ||
| $(RM) $(BOOTIMAGE_NAME_XIP) | ||
| $(RM) $(BOOTIMAGE_NAME_SIGNED) | ||
| $(RM) $(BOOTIMAGE_RPRC_NAME) | ||
| $(RM) $(BOOTIMAGE_RPRC_NAME_XIP) | ||
| $(RM) $(BOOTIMAGE_NAME_MCELF) | ||
| $(RMDIR) generated/ |
There was a problem hiding this comment.
2. Stale rprc not cleaned 🐞 Bug ☼ Reliability
In AM26x FreeRTOS ti-arm-clang makefiles, BOOTIMAGE_RPRC_NAME is still defined but the clean target no longer deletes it. This can leave a stale .rprc file from previous builds/branches in the build directory, making it easy to confuse old artifacts with current outputs during manual debugging/flash workflows.
Agent Prompt
## Issue description
AM26x FreeRTOS ti-arm-clang makefiles still define `BOOTIMAGE_RPRC_NAME`, but `make clean` no longer removes the corresponding `.rprc` file. This leaves stale build outputs behind.
## Issue Context
The PR removed `$(RM) $(BOOTIMAGE_RPRC_NAME)` from the `clean` target while keeping `BOOTIMAGE_RPRC_NAME:=...rprc` defined.
## Fix Focus Areas
- Add back removal in clean for all affected AM26x FreeRTOS ti-arm-clang makefiles (or, alternatively, delete the unused `BOOTIMAGE_RPRC_NAME` variable if `.rprc` is no longer a supported output for these targets).
### Files/lines to update
- academy/getting_started_labs/assembly_code/solution/mcuplus/am261x-lp/r5fss0-0_freertos/ti-arm-clang/makefile[203-212]
(Apply the same change to the analogous AM261x/AM263x/AM263px FreeRTOS `ti-arm-clang/makefile` files touched by this PR.)
ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools
|
Code review by qodo was updated up to the latest commit c037f86 |
|
Thanks for taking the time to mirror and test this, @nsaulnier-ti. I tried to reproduce on my end and wasn't able to get a build failure from a clean tree. A clean serial build of the Both On the log you posted: I think The actual Could you try one of these so we can pin down the real failure?
One env note in case it's relevant: the Happy to dig further once we can see the specific failing command. |
nsaulnier-ti
left a comment
There was a problem hiding this comment.
Reject, replace with #151
|
Closing this in favor of #151, which supersedes it as the more complete, SDK-reference-aligned AM26x port. Thanks @nsaulnier-ti for the thorough diff — your six deltas (the For the record on the earlier build report: on a clean tree the branch here did build green end-to-end for Will follow up on #151 with a small orthogonal hardening suggestion. Thanks again. |
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.