ra: dfu-util .bin for portenta_c33 spans the OPTION_SETTING regions
Maintainers usually reply within 1 day
Nobody has claimed this yet.
Assessment
- Difficulty
- 3/5
- Estimated time
- 1-2 days
- Newbie friendliness
- 58/100
- Issue type
- Bug
- Clarity
- Clearly specified
- Activity status
- Active
- Tech stack
- c, cmake
- Domain
- build-system, embedded-iot
Research direction
Start with hw/bsp/ra/family.cmake:139 and compare its objcopy setup with hw/bsp/ra/family.mk:4-5; the issue identifies hw/bsp/family_support.cmake:524 and :807 as the binary-generation and flash entry points. Build for portenta_c33 and verify the resulting .bin covers only flash sections, then verify it can be flashed with dfu-util.
Written by the indexing model from the issue text.
Description
Deferred from https://github.com/hathach/tinyusb/pull/4146 (#4038). Pre-existing at the PR's base 834c42cb8.
hw/bsp/ra/family.cmake:139 still calls family_add_bin_hex for dfu-util boards. It runs plain objcopy -Obinary (hw/bsp/family_support.cmake:524), and the -dfu-util target flashes that .bin (hw/bsp/family_support.cmake:807).
Evidence
- The
portenta_c33linker script defines OPTION_SETTING regions (hw/bsp/ra/boards/portenta_c33/script/fsp.ld:94-97). On the sibling ra6m5_ek build.option_setting_ofssits at0x0100a100, so the image spans ~16 MB against 2 MB flash. - The make build avoids it with
--only-section(hw/bsp/ra/family.mk:4-5). - #4146 dropped the
.binfor non-DFU RA boards (J-Link flashes the.elf) but kept this one. - Not verified: whether
dfu-util -Dfails or just writes a padded image; no portenta_c33 build was run.
Remaining work
- Restrict the CMake objcopy for RA dfu-util boards to the flash sections, matching
family.mk. - Verify with a portenta_c33 build and a dfu-util flash.
Why deferred: pre-existing at the base; outside #4146's scope.
- Dominant language
- C
- Stars
- 7.2k
- Forks
- 1.6k
- Avg merge
- 1d 12h
- Merged PRs (30d)
- 96
Getting set up
This project ships no dev container, Dockerfile or contributing guide, so setting up is up to you: start from its README, and see our first-contribution guide for the general steps.
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from hathach/tinyusb
-
followup Prio 📌
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
Maintainers usually reply within 1 day
-
followup Prio 📌
Difficulty 2/5 1-3 hours Newbie friendliness 67/100
Maintainers usually reply within 1 day
-
test_audio_host: out-of-bounds read in test_audio_host_uses_exponential_full_speed_iso_intervalOpenfollowup Prio 📌
Difficulty 2/5 1-3 hours Newbie friendliness 84/100
Maintainers usually reply within 1 day
-
followup Prio 📌
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
Maintainers usually reply within 1 day
-
followup Prio 📌
Difficulty 1/5 Under an hour Newbie friendliness 84/100
Maintainers usually reply within 1 day
Similar issues
-
category:port-update
Difficulty 2/5 1-3 hours Newbie friendliness 66/100
Maintainers usually reply within 2 days
-
emerge failure MARK mark-unstable media-kit
Difficulty 2/5 1-3 hours Newbie friendliness 82/100
macaroni-os/mark-issues#834 ·
-
Difficulty 2/5 1-3 hours Newbie friendliness 76/100
-
Difficulty 1/5 Under an hour Newbie friendliness 93/100
webarkit/WebARKitLib#107 ·
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
Maintainers usually reply within 1 day