Fwd: ARM -m startup does not check for idle thread stack space

ange this deep would affect a lot of platforms which I do not have the means to test. WDYT? Carlos From 0dc292a1fa17c9776784e1d4c648bf225ee79710 Mon Sep 17 00:00:00 2001 From: Carlos Sanchez Date: Wed, 2 Nov 2022 11:59:49 +0100 Subject: [PATCH 1/2] Changes to force fill bss section causing s

Re: ARM -m startup does not check for idle thread stack space

> R00= R01= R02=40025000 R03=0004 > > R04= R05=2000c620 R06=0003 R07= > > R08= R09= R10= R11= > > R12= R13=200101e8 R14=0b7b R15=0000 > > XPSR=0003 A handler > > FPSCR: 000

d_len/d_buf arbitration for s32k1xx_flexcan

queue or CAN frames would be lost. Any ideas or anything I might be missing here? Thanks, Carlos -- Carlos Sanchez (he, him, his) Geotab Embedded Systems Developer Team Lead | Europe Visit www.geotab.com Twitter <https://twitter.com/geotab> | Facebook <https://www

Re: d_len/d_buf arbitration for s32k1xx_flexcan

Tue, Jan 3, 2023 at 6:56 PM Xiang Xiao wrote: > Since tx/rx share the same d_len/d_buf, you must do send/recv in one and > only thread(either by system work thread or driver dedicated thread) to > avoid the race condition you describe below. > > On Wed, Jan 4, 2023 at 1:45 AM Carlos S

Re: Re: d_len/d_buf arbitration for s32k1xx_flexcan

ems in the driver, I will create a PR with all this. The interactions with interrupts are a little bit more problematic, though. Best regards, Carlos -- Carlos Sanchez (he, him, his) Geotab Embedded Systems Developer Team Lead | Europe Visit www.geotab.com Twitter <https://twitter.com/ge

Re: Re: d_len/d_buf arbitration for s32k1xx_flexcan

wt., 3 sty 2023 o 19:38 Xiang Xiao napisał(a): > > > Sorry, "you must do..." may confuse you. What I mean is the CAN driver. > > > > On Wed, Jan 4, 2023 at 2:30 AM Carlos Sanchez > > wrote: > > > > > Hi Xiang, > > > > > > P

Re: Re: d_len/d_buf arbitration for s32k1xx_flexcan

, 2023 at 2:56 PM Carlos Sanchez wrote: > Hi Peter, > > >> It seems that calling can_input directly from IRQ got broken since the >> IOB rewrite. >> Before can_input only used dev->d_appdata, but now can_input overwrites >> the dev->d_buf pointer as well. >

SIGEV_THREAD not sharing file descriptors

nx_pthread_create internally for notification actions instead of work queues. Thoughts? BR Carlos -- Carlos Sanchez (he, him, his) Geotab Embedded Systems Developer Team Lead | Europe Visit www.geotab.com Twitter | Facebook | YouTube | LinkedIn

socketcan ioctl(...SIOCSCANBITRATE...) brings the interface up

Hi devs, Short history: in all the existing socketcan drivers in Nuttx (imxrt, s32k3xx, s32k1xx, stm32h7 and kinetis), the driver-specific implementation of ioctl(...SIOCSCANBITRATE...) calls ifup at the end. Is there a rationale / spec for this? Long history: In Linux, CAN bitrate is set with n

Re: [EXT] socketcan ioctl(...SIOCSCANBITRATE...) brings the interface up

ic ifup action that after SIOCSCANBITRATE that currently > happens should be removed. > > The correct procedure to change bitrate would be then > 1. ifdown the interface is it's up > 2. Call SIOCSCANBITRATE > 3. ifup the interface. > > Yours sincerely, > > Pete

Re: [EXT] socketcan ioctl(...SIOCSCANBITRATE...) brings the interface up

> > While testing this, I think I have discovered a small mistake on my > > previous, Nuttx-side PR, which slipped by me and by revision: "ret" > > might be used uninitialized now because I removed the assignment on > > stm32_fdcan_sock:1976 > Yes, please make a PR to fix that!! When it's ready, p

Re: CAN ioctl units (WAS: socketcan ioctl(...SIOCSCANBITRATE...) brings the interface up)

Hi Peter, > can_ioctl_data_s is in a 32-bit union. > https://github.com/apache/nuttx/blob/40c6af6dec0d769ac57f69e89709f9d6310ee0c6/include/net/if.h#L299 > Making it 64-bit would break that union. Maybe I am missing something. AFAIU can_ioctl_data_s is already 64-bit (it includes 4 uint16_t member

Re: CAN ioctl units (WAS: socketcan ioctl(...SIOCSCANBITRATE...) brings the interface up)

; Hence back then it was chosen to use kHz instead. > > > > > > Yours sincerely, > > > > > > Peter van der Perk > > > > > > -Original Message- > > > From: Carlos Sanchez > > > Sent: Wednesday, April 16, 2025 9:37 AM > >

CAN ioctl units (WAS: socketcan ioctl(...SIOCSCANBITRATE...) brings the interface up)

> > I was going to propose another global CAN change, removing the 1000 > > factor from bitrate thus making bitrate calls use units in Hz instead > > of kHz, so we can discuss that and (if agreed) I make the change on > > the same PR to avoid creating so a tiny one. > What's the unit used on Linux

Re: [EXT] socketcan ioctl(...SIOCSCANBITRATE...) brings the interface up

Related PR on the apps side, to make slcan work after the "bitrate no longer brings interface up" change: https://github.com/apache/nuttx-apps/pull/3059 While testing this, I think I have discovered a small mistake on my previous, Nuttx-side PR, which slipped by me and by revision: "ret" might be

Sync using nxsched_foreach might cause long critical sections / deadlocks

compatible with future changes. BR Carlos -- Carlos Sanchez (he, him, his) Geotab Senior Team Lead, Embedded Development | Europe Visit www.geotab.com Twitter | Facebook | YouTube | LinkedIn

Interrupt flood on various stm32_fdcan_sock drivers

stm32h7 driver (https://github.com/apache/nuttx/pull/8250, cc'ing mi colleague Rajvinder as PR author) we brought the problem onto stm32h7 (and probably something similar happened with stm32f0l0g0). Mateusz, WDYT? BR, Carlos -- Carlos Sanchez Geotab