Mchp zephyr dspic release v4.0 #3
Open
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
MuhammedZamroodh
force-pushed
the
mchp_zephyr_dspic_release_v4.0
branch
from
e346da9 to
933d1d4
Compare
MuhammedZamroodh
force-pushed
the
dsPIC33A
branch
from
1d6b675 to
ad4c3e3
Compare
MuhammedZamroodh
force-pushed
the
mchp_zephyr_dspic_release_v4.0
branch
from
933d1d4 to
68ced8c
Compare
|
The following west manifest projects have changed revision in this Pull Request:
✅ All manifest checks OK Note: This message is automatically posted and updated by the Manifest GitHub Action. |
github-actions
bot
added
manifest
manifest-mcuboot
manifest-openthread
manifest-cmsis-dsp
manifest-cmsis_6
manifest-hal_infineon
manifest-hal_ti
manifest-mbedtls
manifest-net-tools
manifest-libsbc
manifest-fatfs
manifest-hal_nxp
manifest-hal_bouffalolab
manifest-lora-basics-modem
manifest-hal_rpi_pico
manifest-hal_stm32
manifest-hal_renesas
manifest-hostap
manifest-hal_adi
manifest-nrf_hw_models
manifest-hal_silabs
manifest-hal_microchip
manifest-hal_ambiq
manifest-hal_ethos_u
manifest-hal_atmel
manifest-trusted-firmware-m
labels
github-actions
bot
removed
manifest-hal_infineon
manifest-hal_ti
manifest-mbedtls
manifest-net-tools
manifest-libsbc
manifest-fatfs
manifest-hal_nxp
manifest-hal_bouffalolab
manifest-lora-basics-modem
manifest-hal_rpi_pico
manifest-hal_stm32
manifest-hal_renesas
manifest-hostap
manifest-hal_adi
manifest-nrf_hw_models
manifest-hal_silabs
manifest-hal_microchip
manifest-hal_ambiq
manifest-hal_ethos_u
manifest-hal_atmel
manifest-trusted-firmware-m
manifest-hal_espressif
manifest-sof
manifest-hal_nordic
manifest-tinycrypt
manifest-nrf_wifi
DNM (manifest)
Binary Blobs Modified
labels
| ? 0 | ||
| : (uint32_t)TMR1 / (uint32_t)TIMER1_CYCLES_PER_TICK; | ||
| ticks_elapsed = | ||
| (uint32_t)TMR1 < (uint32_t)TIMER1_CYCLES_PER_TICK |
There was a problem hiding this comment.
TMR 1 should not be hardcoded as a bigger device can have multiple TMRs. Also, the 128K device has only one TMR1 that is also used as a tick timer for the RTOS but the SCCP can be configured as a Timer and used by the application. This needs to be checked.
There was a problem hiding this comment.
Noted: We will make this driver configurable for different instances of the same IP with DTS.
There was a problem hiding this comment.
We can be addressed in next release
| #include <zephyr/drivers/timer/system_timer.h> | ||
| #include <xc.h> | ||
|
|
||
| #define TIMER1_CYCLES_PER_TICK \ |
There was a problem hiding this comment.
Generic and Kernel timer drivers' must be different
There was a problem hiding this comment.
Clarification: This is the kernel timer driver, used for kernel ticks.
There was a problem hiding this comment.
A driver for generic timer will be different and needs to be implemented.
We can further take this up separately
AzharMCHP
pushed a commit
that referenced
this pull request
Oct 22, 2025
The "_too_small" test variants intentionally configure an isolated buffer
pool with only 2 buffers to validate proper error handling when the pool
is exhausted during notification of 16 msg_subscriber observers. These
tests are likely to fail on SMP systems due to a buffer recycling race
condition:
Expected behavior (uniprocessor):
Publisher Thread:
1. Allocate buf1 for bar_msg_sub1 ✓
2. k_fifo_put(sub1_fifo, buf1)
3. Allocate buf2 for bar_msg_sub2 ✓
4. k_fifo_put(sub2_fifo, buf2)
5. Try allocate buf3 for bar_msg_sub3 → FAIL -ENOMEM
Subscriber threads process messages after notification completes,
pool exhausts at subscriber #3 as expected.
SMP race condition:
CPU 0 (Publisher): CPU 1 (bar_msg_sub1): CPU 2 (bar_msg_sub2):
------------------ --------------------- ---------------------
Alloc buf1 ✓
k_fifo_put(sub1, buf1)
k_fifo_get() → buf1
zbus_sub_wait_msg()
net_buf_unref()
→ buf1 FREED!
Alloc buf2 ✓
(reuses buf1!)
k_fifo_put(sub2, buf2)
k_fifo_get() → buf2
net_buf_unref()
→ buf2 FREED!
Alloc buf3 ✓
(reuses buf1 again!)
...continues...
All 16 allocations succeed!
On SMP systems, subscriber threads on other CPUs may consume and free
buffers quickly enough that they are recycled back to the pool before the
publisher's notification loop can exhaust it. The test's assumption that
notification completes before subscribers run does not hold with parallel
execution.
Since this is a test design limitation (not a zbus bug), filter SMP
configurations from these specific test variants rather than attempt to
artificially slow down subscribers or change thread priorities.
Signed-off-by: Nicolas Pitre <[email protected]>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
4 participants
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Highlights:
- UART interrupt support
- Program memory optimisation
- Support for ztest and twister
- Context switch refignment
- Kernel and thread test cases
- Samples support
- UART: Echo bot, native tty, passthrough
- Blinky
- Philosophers
- Hello world
- Pin control driver
- New board support (sdPIC33AK512MPS512)
Fixes:
- Context switch fixes
- System timer fixes
- Build fixes