Update r5f projects to support latest AM261x sdk by a1248924 · Pull Request #16 · TexasInstruments/pru-no-code-tool

a1248924 · 2026-06-12T14:02:10Z

No description provided.

The merge-base changed after approval.

manojKoppolu

Please make changes as discussed for 64 bit output port

pratheesh-ti · 2026-07-11T05:31:50Z

/agentic_describe

pratheesh-ti · 2026-07-11T05:32:35Z

/agentic_review

qodo-code-review · 2026-07-11T05:35:31Z

PR Summary by Qodo

Update AM261x projects for latest SDK and PRU SPI max-frequency limits

✨ Enhancement ⚙️ Configuration changes 📝 Documentation 🕐 40+ Minutes

AI Description

• Bump AM261x CI builds to MCU+ SDK 26.00.00.06 STS.
• Update PRU SPI SysConfig blocks to use ns-based setup timing and enforce min SCLK widths.
• Migrate AM261x R5F examples to multicore-ELF (.mcelf) bootimage generation and add a 10MHz SPI
 example.

Diagram

graph TD
  A["GitHub Actions"] --> B["AM261x SDK 26.x"] --> C["Example builds"] --> D["Bootimage .mcelf"]
  G["spi_10mhz example"] --> E["SysConfig PRU SPI"] --> F["PRU macros"] --> C --> H["genimage.py + signing"]

  subgraph Legend
    direction LR
    _ci["CI/Build"] ~~~ _cfg["Generators"] ~~~ _ex["Examples"]
  end

High-Level Assessment

The following are alternative approaches to this PR:

1. Centralize PRU-frequency and ns→cycles conversion helper

➕ Eliminates repeated PRU clock lookup and Math.ceil conversions across SPI blocks
➕ Reduces risk of drift between read/write/transfer validation and macro generation
➖ Requires introducing a shared utility in SysConfig meta modules
➖ Slightly larger refactor than a targeted fix

2. Keep Data Setup Time in cycles and document conversion externally

➕ Minimal UI/behavior change for existing users
➖ Error-prone across varying PRU clocks (200/250/333MHz)
➖ Harder to reason about real timing constraints and max frequency

3. Add UI field for computed minimum safe pulse widths

➕ Makes constraints visible and reduces trial-and-error
➕ Improves discoverability of practical (validated) limits
➖ Adds UI surface area to maintain
➖ Still requires the validation fixes already implemented here

Recommendation: Converting Data Setup Time to nanoseconds and deriving cycles from the configured PRU clock is the most robust approach for AM261x clock variants and aligns with CS setup/hold semantics. For follow-up, consider factoring the repeated PRU frequency lookup and ns→cycles conversion into a shared helper to keep SPI read/write/transfer consistent.

Files changed (57) +2904 / -982

Enhancement (9) +931 / -185

pru_spi_read.syscfg.jsSPI Read: ns-based data setup and tighter min SCLK validation +119/-79

SPI Read: ns-based data setup and tighter min SCLK validation
• Treats Data Setup Time as nanoseconds and converts it to PRU cycles using the configured PRU clock. Updates validation, macro loop placement, and documentation for theoretical vs practical maximum frequency guidance.
.metadata/sysconfig/.meta/pru_blocks/pru_io_blocks/pru_spi_read.syscfg.js

pru_spi_transfer.syscfg.jsSPI Transfer: convert setup/hold to cycles and enforce realistic limits +82/-45

SPI Transfer: convert setup/hold to cycles and enforce realistic limits
• Converts CS setup/hold and data setup from ns to PRU cycles at generation time, then updates mode-specific validation and documentation around achievable max SPI frequency (theoretical vs validated practical).
.metadata/sysconfig/.meta/pru_blocks/pru_io_blocks/pru_spi_transfer.syscfg.js

pru_spi_write.syscfg.jsSPI Write: ns-based data setup timing and updated delay components +94/-61

SPI Write: ns-based data setup timing and updated delay components
• Converts Data Setup Time from ns to cycles using PRU clock frequency and adjusts delay component calculations/validation. Updates max-frequency documentation to distinguish theoretical and practical limits.
.metadata/sysconfig/.meta/pru_blocks/pru_io_blocks/pru_spi_write.syscfg.js

example.syscfgAdd PRU0 firmware SysConfig for 10MHz SPI controller +50/-0

Add PRU0 firmware SysConfig for 10MHz SPI controller
• Introduces the PRU0 SysConfig design using the SPI Transfer block with timing tuned for ~10MHz operation.
examples/spi_10mhz/firmware/am261x-lp/icss_m1_pru0_fw/example.syscfg

example.syscfgAdd PRU1 firmware SysConfig for 10MHz SPI peripheral +49/-0

Add PRU1 firmware SysConfig for 10MHz SPI peripheral
• Introduces the PRU1 SysConfig design using the SPI Write block to emulate peripheral responses for loopback validation.
examples/spi_10mhz/firmware/am261x-lp/icss_m1_pru1_fw/example.syscfg

main.asmAdd PRU firmware entry assembly for spi_10mhz +40/-0

Add PRU firmware entry assembly for spi_10mhz
• Adds the PRU assembly entry point used to integrate the generated block code for the spi_10mhz PRU firmwares.
examples/spi_10mhz/firmware/main.asm

example.syscfgAdd R5F SysConfig for spi_10mhz integration +327/-0

Add R5F SysConfig for spi_10mhz integration
• Adds the R5F-side SysConfig enabling ICSS/PRU integration, pin muxing, and required driver configuration for spi_10mhz.
examples/spi_10mhz/mcuplus/am261x-lp/r5fss0-0_freertos/example.syscfg

main.cAdd FreeRTOS entrypoint for spi_10mhz +84/-0

Add FreeRTOS entrypoint for spi_10mhz
• Adds a standard FreeRTOS main that initializes System/Board and runs the example task before starting the scheduler.
examples/spi_10mhz/mcuplus/am261x-lp/r5fss0-0_freertos/main.c

empty_example.cAdd spi_10mhz example logic entry function +86/-0

Add spi_10mhz example logic entry function
• Adds the example entry function invoked by the FreeRTOS main to run the spi_10mhz scenario.
examples/spi_10mhz/mcuplus/empty_example.c

Bug fix (1) +2 / -4

pru_blocks_static_module.syscfg.jsFix UART presence detection to use uart_config module +2/-4

Fix UART presence detection to use uart_config module
• Updates validation logic to detect UART usage via the consolidated uart_config module instead of legacy uart_tx/uart_rx modules.
.metadata/sysconfig/.meta/pru_blocks/common/pru_blocks_static_module.syscfg.js

Refactor (3) +8 / -4

uart_rx_op.syscfg.jsUART RX op: add width-aware output port display name +2/-1

UART RX op: add width-aware output port display name
• Adds a displayName for the output port to indicate 32-bit vs 64-bit output (e.g., out64).
.metadata/sysconfig/.meta/pru_blocks/pru_io_blocks/uart_rx_op.syscfg.js

uart_tx_op.syscfg.jsUART TX op: add width-aware input port display name +2/-1

UART TX op: add width-aware input port display name
• Adds a displayName for the input port to indicate 32-bit vs 64-bit input (e.g., in64).
.metadata/sysconfig/.meta/pru_blocks/pru_io_blocks/uart_tx_op.syscfg.js

memory_access_block.syscfg.jsMemory access block: clarify data port display names +4/-2

Memory access block: clarify data port display names
• Adjusts port display names to better reflect direction/width (e.g., in64/out64) for read/write modes.
.metadata/sysconfig/.meta/pru_blocks/utils/memory_access_block.syscfg.js

Documentation (1) +169 / -0

readme.mdDocument 10MHz SPI configuration and validation +169/-0

Document 10MHz SPI configuration and validation
• Documents the PRU controller/peripheral topology, timing parameter choices (including ns→cycles conversion), and validation notes for achieving ~10MHz SPI.
examples/spi_10mhz/readme.md

Other (43) +1794 / -789

ccs_build.ymlBump AM261x CI SDK to 26.00.00.06 STS +3/-3

Bump AM261x CI SDK to 26.00.00.06 STS
• Updates the AM261x MCU+ SDK version, installer name, and download URL used by the CCS workflow matrix.
.github/workflows/ccs_build.yml

makefile.ymlBump AM261x CI SDK to 26.00.00.06 STS +3/-3

Bump AM261x CI SDK to 26.00.00.06 STS
• Updates the AM261x MCU+ SDK version, installer name, and download URL used by the makefile workflow matrix.
.github/workflows/makefile.yml

product.jsonAdd AM261x variants and ICSS PRU target contexts +29/-1

Add AM261x variants and ICSS PRU target contexts
• Adds new AM261x part variants (e.g., ZNC, ZFG_400) and maps them to ICSS PRU targetdb contexts for project generation.
.metadata/product.json

example.projectspecConditional example: align products and library names with new SDK +5/-5

Conditional example: align products and library names with new SDK
• Removes PRU_NO_CODE_TOOL from required products and updates driver/board library names to the FreeRTOS-suffixed variants.
examples/conditional/mcuplus/am261x-lp/r5fss0-0_freertos/ti-arm-clang/example.projectspec

makefileConditional example: migrate bootimage to multicore-ELF (.mcelf) flow +51/-69

Conditional example: migrate bootimage to multicore-ELF (.mcelf) flow
• Replaces legacy appimage/rprc bootimage generation with multicore-ELF generation and updated signing/encryption scripts. Updates core IDs/SBL run address and aligns library naming with the latest SDK.
examples/conditional/mcuplus/am261x-lp/r5fss0-0_freertos/ti-arm-clang/makefile

makefile.defsConditional example: include .mcelf outputs in generated-file patterns +14/-0

Conditional example: include .mcelf outputs in generated-file patterns
• Adds multicore-ELF-related artifact patterns to the generated-file list used for cleanup/packaging.
examples/conditional/mcuplus/am261x-lp/r5fss0-0_freertos/ti-arm-clang/makefile.defs

makefile_ccs_bootimage_genConditional example (CCS): generate/sign multicore-ELF +38/-56

Conditional example (CCS): generate/sign multicore-ELF
• Updates CCS post-build bootimage generation to multicore-ELF tooling and updated signing/encryption flows; switches imports include to MCU+ SDK imports.
examples/conditional/mcuplus/am261x-lp/r5fss0-0_freertos/ti-arm-clang/makefile_ccs_bootimage_gen

example.projectspecEmpty example: align products and library names with new SDK +4/-4

Empty example: align products and library names with new SDK
• Removes PRU_NO_CODE_TOOL from required products and updates driver/board library names to the FreeRTOS-suffixed variants.
examples/empty/mcuplus/am261x-lp/r5fss0-0_freertos/ti-arm-clang/example.projectspec

makefileEmpty example: migrate bootimage to multicore-ELF (.mcelf) flow +51/-71

Empty example: migrate bootimage to multicore-ELF (.mcelf) flow
• Migrates bootimage generation/signing to multicore-ELF and updates core IDs/SBL run address. Aligns linked library naming with the latest SDK outputs.
examples/empty/mcuplus/am261x-lp/r5fss0-0_freertos/ti-arm-clang/makefile

makefile.defsEmpty example: include .mcelf outputs in generated-file patterns +14/-0

Empty example: include .mcelf outputs in generated-file patterns
• Adds multicore-ELF-related artifact patterns to the generated-file list used for cleanup/packaging.
examples/empty/mcuplus/am261x-lp/r5fss0-0_freertos/ti-arm-clang/makefile.defs

makefile_ccs_bootimage_genEmpty example (CCS): generate/sign multicore-ELF +38/-57

Empty example (CCS): generate/sign multicore-ELF
• Updates CCS post-build steps to use multicore-ELF generation and updated signing/encryption flows consistent with the latest SDK.
examples/empty/mcuplus/am261x-lp/r5fss0-0_freertos/ti-arm-clang/makefile_ccs_bootimage_gen

example.projectspecGray encoder: align products and library names with new SDK +5/-5

Gray encoder: align products and library names with new SDK
• Removes PRU_NO_CODE_TOOL from required products and updates driver/board library names to the FreeRTOS-suffixed variants.
examples/gray_encoder_4_bit/mcuplus/am261x-lp/r5fss0-0_freertos/ti-arm-clang/example.projectspec

makefileGray encoder: migrate bootimage to multicore-ELF (.mcelf) flow +51/-69

Gray encoder: migrate bootimage to multicore-ELF (.mcelf) flow
• Migrates bootimage generation/signing to multicore-ELF and updates core IDs/SBL run address. Aligns library naming with the latest SDK outputs.
examples/gray_encoder_4_bit/mcuplus/am261x-lp/r5fss0-0_freertos/ti-arm-clang/makefile

makefile.defsGray encoder: include .mcelf outputs in generated-file patterns +14/-0

Gray encoder: include .mcelf outputs in generated-file patterns
• Adds multicore-ELF-related artifact patterns to the generated-file list used for cleanup/packaging.
examples/gray_encoder_4_bit/mcuplus/am261x-lp/r5fss0-0_freertos/ti-arm-clang/makefile.defs

makefile_ccs_bootimage_genGray encoder (CCS): generate/sign multicore-ELF +38/-56

Gray encoder (CCS): generate/sign multicore-ELF
• Updates CCS post-build steps to use multicore-ELF generation and updated signing/encryption scripts.
examples/gray_encoder_4_bit/mcuplus/am261x-lp/r5fss0-0_freertos/ti-arm-clang/makefile_ccs_bootimage_gen

example.projectspecIncremental SPI: align products and library names with new SDK +5/-5

Incremental SPI: align products and library names with new SDK
• Removes PRU_NO_CODE_TOOL from required products and updates driver/board library names to the FreeRTOS-suffixed variants.
examples/incremental_spi/mcuplus/am261x-lp/r5fss0-0_freertos/ti-arm-clang/example.projectspec

makefileIncremental SPI: migrate bootimage to multicore-ELF (.mcelf) flow +51/-69

Incremental SPI: migrate bootimage to multicore-ELF (.mcelf) flow
• Migrates bootimage generation/signing to multicore-ELF and updates core IDs/SBL run address. Aligns library naming with the latest SDK outputs.
examples/incremental_spi/mcuplus/am261x-lp/r5fss0-0_freertos/ti-arm-clang/makefile

makefile.defsIncremental SPI: include .mcelf outputs in generated-file patterns +14/-0

Incremental SPI: include .mcelf outputs in generated-file patterns
• Adds multicore-ELF-related artifact patterns to the generated-file list used for cleanup/packaging.
examples/incremental_spi/mcuplus/am261x-lp/r5fss0-0_freertos/ti-arm-clang/makefile.defs

makefile_ccs_bootimage_genIncremental SPI (CCS): generate/sign multicore-ELF +38/-56

Incremental SPI (CCS): generate/sign multicore-ELF
• Updates CCS post-build steps to use multicore-ELF generation and updated signing/encryption scripts.
examples/incremental_spi/mcuplus/am261x-lp/r5fss0-0_freertos/ti-arm-clang/makefile_ccs_bootimage_gen

makefileAdd spi_10mhz to the examples build list +1/-0

Add spi_10mhz to the examples build list
• Includes the new spi_10mhz example directory in the top-level examples makefile SUBDIRS.
examples/makefile

example.projectspecAdd PRU0 firmware CCS projectspec +83/-0

Add PRU0 firmware CCS projectspec
• Adds a PRU CGT projectspec to build the PRU0 firmware for the spi_10mhz example.
examples/spi_10mhz/firmware/am261x-lp/icss_m1_pru0_fw/ti-pru-cgt/example.projectspec

linker.cmdAdd PRU0 firmware linker script +54/-0

Add PRU0 firmware linker script
• Provides the PRU0 firmware memory/linker layout required by the spi_10mhz firmware build.
examples/spi_10mhz/firmware/am261x-lp/icss_m1_pru0_fw/ti-pru-cgt/linker.cmd

makefileAdd PRU0 firmware makefile +55/-0

Add PRU0 firmware makefile
• Adds build rules for PRU0 firmware using ti-pru-cgt for spi_10mhz.
examples/spi_10mhz/firmware/am261x-lp/icss_m1_pru0_fw/ti-pru-cgt/makefile

makefile_projectspecAdd PRU0 firmware projectspec build wrapper +16/-0

Add PRU0 firmware projectspec build wrapper
• Adds a helper makefile to build/import the PRU0 CCS projectspec consistently.
examples/spi_10mhz/firmware/am261x-lp/icss_m1_pru0_fw/ti-pru-cgt/makefile_projectspec

example.projectspecAdd PRU1 firmware CCS projectspec +83/-0

Add PRU1 firmware CCS projectspec
• Adds a PRU CGT projectspec to build the PRU1 firmware for the spi_10mhz example.
examples/spi_10mhz/firmware/am261x-lp/icss_m1_pru1_fw/ti-pru-cgt/example.projectspec

linker.cmdAdd PRU1 firmware linker script +54/-0

Add PRU1 firmware linker script
• Provides the PRU1 firmware memory/linker layout required by the spi_10mhz firmware build.
examples/spi_10mhz/firmware/am261x-lp/icss_m1_pru1_fw/ti-pru-cgt/linker.cmd

makefileAdd PRU1 firmware makefile +55/-0

Add PRU1 firmware makefile
• Adds build rules for PRU1 firmware using ti-pru-cgt for spi_10mhz.
examples/spi_10mhz/firmware/am261x-lp/icss_m1_pru1_fw/ti-pru-cgt/makefile

makefile_projectspecAdd PRU1 firmware projectspec build wrapper +16/-0

Add PRU1 firmware projectspec build wrapper
• Adds a helper makefile to build/import the PRU1 CCS projectspec consistently.
examples/spi_10mhz/firmware/am261x-lp/icss_m1_pru1_fw/ti-pru-cgt/makefile_projectspec

makefileAdd top-level build orchestration for spi_10mhz +106/-0

Add top-level build orchestration for spi_10mhz
• Introduces a top-level makefile to build the spi_10mhz example across firmware and MCU+ components.
examples/spi_10mhz/makefile

example.projectspecAdd CCS projectspec for spi_10mhz R5F app +116/-0

Add CCS projectspec for spi_10mhz R5F app
• Adds a ti-arm-clang CCS projectspec for building the spi_10mhz R5F FreeRTOS application.
examples/spi_10mhz/mcuplus/am261x-lp/r5fss0-0_freertos/ti-arm-clang/example.projectspec

makefileAdd ti-arm-clang makefile for spi_10mhz (multicore-ELF flow) +336/-0

Add ti-arm-clang makefile for spi_10mhz (multicore-ELF flow)
• Adds a dedicated ti-arm-clang makefile for spi_10mhz aligned to multicore-ELF bootimage generation and HS signing/encryption flows.
examples/spi_10mhz/mcuplus/am261x-lp/r5fss0-0_freertos/ti-arm-clang/makefile

makefile.defsAdd generated-file patterns for spi_10mhz outputs +14/-0

Add generated-file patterns for spi_10mhz outputs
• Defines generated artifact patterns for cleanup/packaging, including multicore-ELF outputs.
examples/spi_10mhz/mcuplus/am261x-lp/r5fss0-0_freertos/ti-arm-clang/makefile.defs

makefile_ccs_bootimage_genAdd CCS post-build multicore-ELF generation for spi_10mhz +95/-0

Add CCS post-build multicore-ELF generation for spi_10mhz
• Adds CCS post-build steps to generate multicore-ELF outputs and optionally sign/encrypt them for HS configurations.
examples/spi_10mhz/mcuplus/am261x-lp/r5fss0-0_freertos/ti-arm-clang/makefile_ccs_bootimage_gen

makefile_projectspecAdd projectspec build wrapper for spi_10mhz +16/-0

Add projectspec build wrapper for spi_10mhz
• Adds a helper makefile to build/import the spi_10mhz CCS projectspec consistently.
examples/spi_10mhz/mcuplus/am261x-lp/r5fss0-0_freertos/ti-arm-clang/makefile_projectspec

syscfg_c.rov.xsAdd ROV script for SysConfig-generated C (spi_10mhz) +12/-0

Add ROV script for SysConfig-generated C (spi_10mhz)
• Adds ROV integration for inspecting SysConfig-generated data for the spi_10mhz R5F project.
examples/spi_10mhz/mcuplus/am261x-lp/r5fss0-0_freertos/ti-arm-clang/syscfg_c.rov.xs

example.projectspecSPI loopback: align products and library names with new SDK +5/-5

SPI loopback: align products and library names with new SDK
• Removes PRU_NO_CODE_TOOL from required products and updates driver/board library names to the FreeRTOS-suffixed variants.
examples/spi_loopback/mcuplus/am261x-lp/r5fss0-0_freertos/ti-arm-clang/example.projectspec

makefileSPI loopback: migrate bootimage to multicore-ELF (.mcelf) flow +51/-69

SPI loopback: migrate bootimage to multicore-ELF (.mcelf) flow
• Migrates bootimage generation/signing to multicore-ELF and updates core IDs/SBL run address to match the latest SDK flow.
examples/spi_loopback/mcuplus/am261x-lp/r5fss0-0_freertos/ti-arm-clang/makefile

makefile.defsSPI loopback: include .mcelf outputs in generated-file patterns +14/-0

SPI loopback: include .mcelf outputs in generated-file patterns
• Adds multicore-ELF-related artifact patterns to the generated-file list used for cleanup/packaging.
examples/spi_loopback/mcuplus/am261x-lp/r5fss0-0_freertos/ti-arm-clang/makefile.defs

makefile_ccs_bootimage_genSPI loopback (CCS): generate/sign multicore-ELF +38/-56

SPI loopback (CCS): generate/sign multicore-ELF
• Updates CCS post-build steps to use multicore-ELF tooling and updated signing/encryption scripts.
examples/spi_loopback/mcuplus/am261x-lp/r5fss0-0_freertos/ti-arm-clang/makefile_ccs_bootimage_gen

example.projectspecUART CRC: align products and library names with new SDK +5/-5

UART CRC: align products and library names with new SDK
• Removes PRU_NO_CODE_TOOL from required products and updates driver/board library names to the FreeRTOS-suffixed variants.
examples/uart_crc/mcuplus/am261x-lp/r5fss0-0_freertos/ti-arm-clang/example.projectspec

makefileUART CRC: migrate bootimage to multicore-ELF (.mcelf) flow +51/-69

UART CRC: migrate bootimage to multicore-ELF (.mcelf) flow
• Migrates bootimage generation/signing to multicore-ELF and updates core IDs/SBL run address to match the latest SDK flow.
examples/uart_crc/mcuplus/am261x-lp/r5fss0-0_freertos/ti-arm-clang/makefile

makefile.defsUART CRC: include .mcelf outputs in generated-file patterns +14/-0

UART CRC: include .mcelf outputs in generated-file patterns
• Adds multicore-ELF-related artifact patterns to the generated-file list used for cleanup/packaging.
examples/uart_crc/mcuplus/am261x-lp/r5fss0-0_freertos/ti-arm-clang/makefile.defs

makefile_ccs_bootimage_genUART CRC (CCS): generate/sign multicore-ELF +38/-56

UART CRC (CCS): generate/sign multicore-ELF
• Updates CCS post-build steps to use multicore-ELF tooling and updated signing/encryption scripts.
examples/uart_crc/mcuplus/am261x-lp/r5fss0-0_freertos/ti-arm-clang/makefile_ccs_bootimage_gen

qodo-code-review · 2026-07-11T05:37:39Z

Code Review by Qodo

🐞 Bugs (0) 📘 Rule violations (1) 📎 Requirement gaps (0) 🎨 UX issues (0) 🔗 Cross-repo conflicts (0) 📜 Skill insights (0)

1. ~~Invalid JSON trailing comma~~ ✓ Resolved 🐞 Bug ≡ Correctness

Description

.metadata/product.json now has a trailing comma after the last element in the "devices" array, which
makes the file invalid JSON. Any consumer using a strict JSON parser will fail to load this product
metadata.

Code

.metadata/product.json[R17-20]

+        "AM261x_ZCZ",
+        "AM261x_ZNC",
+        "AM261x_ZFG_400",
    ],

Evidence

The devices array ends with "AM261x_ZFG_400", followed by a comma before the closing bracket, which
is not permitted in JSON.

.metadata/product.json[12-21]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

### Issue description
`.metadata/product.json` is no longer valid JSON because the last entry in the `devices` array ends with a trailing comma.

### Issue Context
Strict JSON parsers reject trailing commas, which can break product loading/metadata processing.

### Fix Focus Areas
- .metadata/product.json[12-21]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

2. Ambiguous block names in syscfg 📘 Rule violation ⚙ Maintainability Rule 2

Description

The newly added PRU0 and PRU1 SPI block instances use default/type-only names (e.g.,
Load_Constant_0, Flow_Control_0) instead of purpose-based names. This reduces
readability/reviewability and increases the risk of miswiring or errors during future modifications.

Code

examples/spi_10mhz/firmware/am261x-lp/icss_m1_pru0_fw/example.syscfg[R23-28]

+load_constant_block1.$name     = "Load_Constant_0";
+load_constant_block1.constant1 = 2882400171;
+
+flow_control_block1.$name = "Flow_Control_0";
+
+pru_spi_transfer1.$name                                    = "PRU0_SPI_Transfer_0";

Evidence
PR Compliance ID 1 requires semantic, purpose-based block instance names in .syscfg; however, in
example.syscfg for both the PRU0 and PRU1 SPI firmware, the added instances are explicitly given
ambiguous default names such as Load_Constant_0 and Flow_Control_0, along with SPI-related
instances like PRU0_SPI_Transfer_0 and PRU1_SPI_Write_0, rather than names that describe their
intended role/purpose.
Rule Rule 2: Use Semantic Purpose-Based Names for Blocks
examples/spi_10mhz/firmware/am261x-lp/icss_m1_pru0_fw/example.syscfg[23-28]
examples/spi_10mhz/firmware/am261x-lp/icss_m1_pru1_fw/example.syscfg[25-30]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
New block instances in the `.syscfg` use ambiguous default/type-only `$name` values (e.g., `Load_Constant_0`, `Flow_Control_0`) instead of semantic purpose-based names.

## Issue Context
PR Compliance ID 1 requires block instance names to describe their role/purpose to prevent connection mistakes and improve reviewability. The PRU0 and PRU1 SPI `.syscfg` files currently include newly added instances with default-style names (including SPI-related instances like `PRU0_SPI_Transfer_0` and `PRU1_SPI_Write_0`) that should be renamed to reflect their functional intent.

## Fix Focus Areas
- examples/spi_10mhz/firmware/am261x-lp/icss_m1_pru0_fw/example.syscfg[23-28]
- examples/spi_10mhz/firmware/am261x-lp/icss_m1_pru1_fw/example.syscfg[25-30]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

3. ~~UART TX port label wrong~~ ✓ Resolved 🐞 Bug ⚙ Maintainability

Description

uart_tx_op.syscfg.js labels the 32-bit input port's displayName as "output1", which contradicts
the port direction and is inconsistent with the 64-bit case ("in64"). This is user-facing in
SysConfig and can confuse users when wiring blocks.

Code

.metadata/sysconfig/.meta/pru_blocks/pru_io_blocks/uart_tx_op.syscfg.js[R960-966]

    ports: (inst) => {
        const dataBits = inst.dataBits;
        const inputType = dataBits > 32 ? "input64" : "input32";
+        const portName = inputType === "input64" ? "in64" : "output1" 
        return [
-            { name: "input1", type: inputType },
+            { name: "input1", type: inputType, displayName: portName },
            { name: "prev",   type: "PREV" },

Evidence
The code explicitly sets portName to "output1" when inputType is "input32", and assigns it to
the displayName of the input1 port.
.metadata/sysconfig/.meta/pru_blocks/pru_io_blocks/uart_tx_op.syscfg.js[960-968]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

### Issue description
In `uart_tx_op.syscfg.js`, the 32-bit input port is given a `displayName` of `output1`, which is misleading for an input.

### Issue Context
This appears to be a copy/paste typo (the 64-bit case uses `in64`). Similar blocks use `input1`/`in64` for input ports.

### Fix Focus Areas
- .metadata/sysconfig/.meta/pru_blocks/pru_io_blocks/uart_tx_op.syscfg.js[960-968]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

_{To customize comments, go to the Qodo configuration screen, or learn more in the docs.}

pratheesh-ti · 2026-07-21T11:01:27Z

/agentic_review

The UART-not-simulated warning checked for the old uart_tx/uart_rx modules, which no longer exist after the UART refactor into uart_config/uart_tx_op/uart_rx_op. The check silently never fired.

Data Splitter, Memory Access, UART RX Op, and UART TX Op ports switch between 32-bit and 64-bit types depending on config; the port now labels itself in64/out64 in the 64-bit case instead of showing the generic input1/output1 name.

Reorder the delay-compensation loops relative to the Data Setup Time wait in the bit-read sequence (SCLK edge was toggling before the data setup delay completed), and account for Data Setup Time cycles in the validate() minimum SCLK width checks for all four SPI modes. This lowers the real achievable max frequency for SPI Read/Transfer; update the block docs and README table to report the corrected practical max frequencies instead of the unattainable theoretical ones.

Full SPI loopback example running at 10 MHz on AM261x-LP, including PRU firmware, MCU+ R5F application, and build files for CCS and makefile-based builds. Wired into examples/makefile SUBDIRS.

qodo-code-review · 2026-07-21T11:11:28Z

Code Review by Qodo

🐞 Bugs (0) 📘 Rule violations (1) 📎 Requirement gaps (0) 🎨 UX issues (0) 🔗 Cross-repo conflicts (0) 📜 Skill insights (0)

1. ~~otfaConfigFile passed as None~~ ✓ Resolved 🐞 Bug ☼ Reliability

Description

AM261x MCU+ makefiles default oeconfig to the literal string None and always pass it to
genimage.py via --otfaConfigFile=$(oeconfig), so the command line becomes
--otfaConfigFile=None unless overridden. This can cause multicore-ELF boot image generation to
behave unexpectedly when no OTFA config is intended, since a non-empty sentinel value is being
supplied instead of omitting the option.

Code

examples/conditional/mcuplus/am261x-lp/r5fss0-0_freertos/ti-arm-clang/makefile[R292-294]

+$(BOOTIMAGE_NAME_MCELF): $(OUTNAME)
+	@echo  Boot MulticoreELF image: $(BOOTIMAGE_PATH)/$(BOOTIMAGE_NAME_MCELF) ...
+	$(PYTHON) $(MCELF_IMAGE_GEN) --core-img=$(BOOTIMAGE_CORE_ID_r5fss0-0):$(OUTNAME) --output=$(BOOTIMAGE_NAME_MCELF) --merge-segments=$(MCELF_MERGE_SEGMENTS_FLAG) --tolerance-limit=$(MCELF_MERGE_SEGMENTS_TOLERANCE_LIMIT) --ignore-context=$(MCELF_IGNORE_CONTEXT_FLAG) --xip=$(MCELF_XIP_RANGE) --xlat=$(MCELF_ADDR_TRANSLATION_PATH) --max-segment-size=$(MCELF_MAX_SEGMENT_SIZE) --otfaConfigFile=$(oeconfig)

Evidence
The makefile sets oeconfig to the string None by default, and the genimage invocation always
appends --otfaConfigFile=$(oeconfig), meaning None will be passed literally unless the caller
overrides it.
examples/conditional/mcuplus/am261x-lp/r5fss0-0_freertos/ti-arm-clang/makefile[31-40]
examples/conditional/mcuplus/am261x-lp/r5fss0-0_freertos/ti-arm-clang/makefile[289-295]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
AM261x MCU+ makefiles set `oeconfig?=None` and unconditionally add `--otfaConfigFile=$(oeconfig)` to the multicore-ELF `genimage.py` command, which results in passing the literal string `None` as a file argument by default.

## Issue Context
This affects AM261x MCU+ example makefiles and impacts boot image generation invoked from `make`.

## Fix Focus Areas
- examples/conditional/mcuplus/am261x-lp/r5fss0-0_freertos/ti-arm-clang/makefile[31-40]
- examples/conditional/mcuplus/am261x-lp/r5fss0-0_freertos/ti-arm-clang/makefile[292-295]

### Suggested fix
- Change the default to empty (e.g., `oeconfig ?=`).
- Only append `--otfaConfigFile=...` when `oeconfig` is non-empty (and ideally when the referenced file exists).
- Apply the same pattern to the other AM261x MCU+ makefiles that use `oeconfig` similarly.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

2. flow_control_block1.prev drives next 📘 Rule violation ≡ Correctness

Description

example.syscfg connects flow_control_block1's prev port to SPI blocks’ next ports
(pru_spi_transfer1.next / pru_spi_write1.next), reversing the intended next → prev
control-flow direction and incorrectly using an input (prev) as the connection source. This can
break control-flow wiring/execution order and may be rejected by SysConfig or produce incorrect
generated code.

Code

examples/spi_10mhz/firmware/am261x-lp/icss_m1_pru0_fw/example.syscfg[43]
+scripting.connect(flow_control_block1, "prev", pru_spi_transfer1, "next");

Evidence
PR Compliance ID 2 requires correct control-flow port naming and direction, specifically wiring
control flow from a producer’s next output into a consumer’s prev input (next → prev). The
cited .syscfg changes instead create connections that originate from flow_control_block1.prev
and terminate at pru_spi_transfer1.next and pru_spi_write1.next, which contradicts the Flow
Control block’s declared/expected port roles (with prev being an input on a terminating block) and
the documented connection pattern, thereby evidencing the reversed/invalid control-flow wiring.
AGENTS.md: Use Correct Connection Port Names for Data vs Control Flow
examples/spi_10mhz/firmware/am261x-lp/icss_m1_pru0_fw/example.syscfg[42-43]
.metadata/sysconfig/.meta/pru_blocks/program_control/flow_control_block.syscfg.js[52-66]
examples/spi_10mhz/firmware/am261x-lp/icss_m1_pru1_fw/example.syscfg[41-42]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
The control-flow `scripting.connect()` calls are reversed: they use `flow_control_block1.prev` (an input on a terminating Flow Control block) as the source and connect into SPI blocks’ `next` ports (`pru_spi_transfer1.next` / `pru_spi_write1.next`), instead of wiring `prev_block.next` into `flow_control_block1.prev`.

## Issue Context
PR Compliance ID 2 requires correct control-flow port naming and direction (`next` → `prev`). `Flow Control` is a terminating block (no `next` output), and the documented connection pattern is `prev_block.next` -> `flow.prev`; SPI blocks expose `prev`/`next` for control flow, so the flow should be driven from an upstream block’s `next` output into the Flow Control block’s `prev` input.

## Fix Focus Areas
- examples/spi_10mhz/firmware/am261x-lp/icss_m1_pru0_fw/example.syscfg[42-43]
- examples/spi_10mhz/firmware/am261x-lp/icss_m1_pru1_fw/example.syscfg[41-42]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

3. ~~MODE2 delay comments contradict~~ ✓ Resolved 🐞 Bug ⚙ Maintainability

Description

In pru_spi_read.syscfg.js, the new MODE2 timing comments for delay_component1/delay_component2
contradict the implemented formulas (e.g., comment states delay_component1 subtracts dataSetup,
but the code does not; another comment says dataSetup is “not here” while the code subtracts it).
This inconsistency increases the risk of future timing regressions because reviewers/maintainers
cannot trust which half-cycle the code is actually compensating.

Code

.metadata/sysconfig/.meta/pru_blocks/pru_io_blocks/pru_spi_read.syscfg.js[R1233-1235]

+				// MODE2: DATA_SETUP_TIME is in the HIGH half (before CLR SCLK sampling edge)
+				// HIGH half overhead: sub(1) + dataSetup + DELAY_COMPEN_1 → delay_component1 = low - 1 - dataSetup (using low as HIGH pulse base)
+				else if (mode === "MODE2") value = low - 4 ;

Evidence
The file shows MODE2 comments claiming a - dataSetup adjustment in one place where the code does
not, and claiming dataSetup is not included in another place where the code explicitly subtracts it.
.metadata/sysconfig/.meta/pru_blocks/pru_io_blocks/pru_spi_read.syscfg.js[1226-1236]
.metadata/sysconfig/.meta/pru_blocks/pru_io_blocks/pru_spi_read.syscfg.js[1276-1279]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
The MODE2 comments around `delay_component1` and `delay_component2` calculations contradict the actual expressions, which makes the SPI timing logic error-prone to maintain.

## Issue Context
This is in the PRU SPI Read block SysConfig meta module where delay components and DATA_SETUP_TIME interactions are subtle and mode-dependent.

## Fix Focus Areas
- .metadata/sysconfig/.meta/pru_blocks/pru_io_blocks/pru_spi_read.syscfg.js[1226-1236]
- .metadata/sysconfig/.meta/pru_blocks/pru_io_blocks/pru_spi_read.syscfg.js[1276-1279]

### Suggested fix
- Re-verify MODE2 timing placement for DATA_SETUP_TIME vs DELAY_COMPEN_1/2 in the generated macro.
- Update the comments to match the implemented formulas (or adjust the formulas if the comments reflect the intended behavior).
- Keep comments consistent across `validate()` minimums and delay component calculations for the same mode.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

_{To customize comments, go to the Qodo configuration screen, or learn more in the docs.}

a1248924 · 2026-07-22T06:05:42Z

/agentic_review

qodo-code-review · 2026-07-22T06:05:48Z

Qodo reviews are paused for this user.

Troubleshooting steps vary by plan Learn more →

On a Teams plan?
Reviews resume once this user has a paid seat and their Git account is linked in Qodo.
Link Git account →

Using GitHub Enterprise Server, GitLab Self-Managed, or Bitbucket Data Center?
These require an Enterprise plan - Contact us
Contact us →

qodo-code-review · 2026-07-22T06:11:56Z

Qodo reviews are paused for this user.

Troubleshooting steps vary by plan Learn more →

On a Teams plan?
Reviews resume once this user has a paid seat and their Git account is linked in Qodo.
Link Git account →

Using GitHub Enterprise Server, GitLab Self-Managed, or Bitbucket Data Center?
These require an Enterprise plan - Contact us
Contact us →

Bump am261x MCU+ SDK from 10.02.00.15 to 26.00.00.06 in CI workflows, add AM261x_ZNC and AM261x_ZFG_400 device variants to product.json, and regenerate CCS/makefile build files for all existing am261x-lp examples against the new SDK.

a1248924 force-pushed the spi_issue branch 6 times, most recently from 7501bac to 5ff5fbf Compare June 22, 2026 11:40

a1248924 changed the title ~~Spi issue~~ Update r5f projects to support latest AM261x sdk Jun 22, 2026

dhavaljk previously approved these changes Jul 2, 2026

View reviewed changes

pratheesh-ti requested review from manojKoppolu and pratheesh-ti July 5, 2026 14:42

manojKoppolu requested changes Jul 7, 2026

View reviewed changes

a1248924 force-pushed the spi_issue branch from 5ff5fbf to 0fe47ed Compare July 7, 2026 07:16

a1248924 requested a review from manojKoppolu July 7, 2026 11:27

qodo-code-review Bot reviewed Jul 11, 2026

View reviewed changes

Comment thread examples/spi_10mhz/firmware/am261x-lp/icss_m1_pru0_fw/example.syscfg

Comment thread .metadata/product.json

Comment thread .metadata/sysconfig/.meta/pru_blocks/pru_io_blocks/uart_tx_op.syscfg.js

a1248924 force-pushed the spi_issue branch from 0fe47ed to 7347ff4 Compare July 19, 2026 19:14

manojKoppolu previously approved these changes Jul 21, 2026

View reviewed changes

a1248924 added 4 commits July 21, 2026 16:38

Fix stale uart_tx/uart_rx module reference in static module validator

a64ebbd

The UART-not-simulated warning checked for the old uart_tx/uart_rx modules, which no longer exist after the UART refactor into uart_config/uart_tx_op/uart_rx_op. The check silently never fired.

Add displayName to 64-bit split ports (in64/out64)

140578c

Data Splitter, Memory Access, UART RX Op, and UART TX Op ports switch between 32-bit and 64-bit types depending on config; the port now labels itself in64/out64 in the 64-bit case instead of showing the generic input1/output1 name.

Add spi_10mhz example project

2da9d29

Full SPI loopback example running at 10 MHz on AM261x-LP, including PRU firmware, MCU+ R5F application, and build files for CCS and makefile-based builds. Wired into examples/makefile SUBDIRS.

qodo-code-review Bot reviewed Jul 21, 2026

View reviewed changes

Comment thread examples/spi_10mhz/firmware/am261x-lp/icss_m1_pru0_fw/example.syscfg

Comment thread examples/conditional/mcuplus/am261x-lp/r5fss0-0_freertos/ti-arm-clang/makefile

Comment thread .metadata/sysconfig/.meta/pru_blocks/pru_io_blocks/pru_spi_read.syscfg.js Outdated

a1248924 force-pushed the spi_issue branch from 7347ff4 to b7ca411 Compare July 21, 2026 11:12

a1248924 dismissed manojKoppolu’s stale review via 157865d July 22, 2026 06:21

a1248924 force-pushed the spi_issue branch from b7ca411 to 157865d Compare July 22, 2026 06:21

TexasInstruments deleted a comment from qodo-code-review Bot Jul 22, 2026

a1248924 force-pushed the spi_issue branch from 157865d to 43b814c Compare July 22, 2026 06:36

a1248924 requested review from dhavaljk and manojKoppolu July 27, 2026 06:05

dhavaljk previously approved these changes Jul 31, 2026

View reviewed changes

manojKoppolu requested changes Jul 31, 2026

View reviewed changes

Comment thread examples/conditional/mcuplus/am261x-lp/r5fss0-0_freertos/ti-arm-clang/example.projectspec

Comment thread ...ples/conditional/mcuplus/am261x-lp/r5fss0-0_freertos/ti-arm-clang/makefile_ccs_bootimage_gen

a1248924 dismissed dhavaljk’s stale review via 34ae9c1 August 4, 2026 17:55

a1248924 force-pushed the spi_issue branch from 43b814c to 34ae9c1 Compare August 4, 2026 17:55

a1248924 requested review from dhavaljk and manojKoppolu August 5, 2026 06:13

Uh oh!

Conversation

a1248924 commented Jun 12, 2026

Uh oh!

manojKoppolu left a comment

Choose a reason for hiding this comment

Uh oh!

pratheesh-ti commented Jul 11, 2026

Uh oh!

pratheesh-ti commented Jul 11, 2026

Uh oh!

qodo-code-review Bot commented Jul 11, 2026

PR Summary by Qodo

Uh oh!

qodo-code-review Bot commented Jul 11, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Code Review by Qodo

Uh oh!

Uh oh!

Uh oh!

Uh oh!

pratheesh-ti commented Jul 21, 2026

Uh oh!

qodo-code-review Bot commented Jul 21, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Code Review by Qodo

Uh oh!

Uh oh!

Uh oh!

Uh oh!

a1248924 commented Jul 22, 2026

Uh oh!

qodo-code-review Bot commented Jul 22, 2026

Qodo reviews are paused for this user.

Uh oh!

qodo-code-review Bot commented Jul 22, 2026

Qodo reviews are paused for this user.

Uh oh!

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

qodo-code-review Bot commented Jul 11, 2026 •

edited

Loading

qodo-code-review Bot commented Jul 21, 2026 •

edited

Loading