Hello,
There is a typo in the PCA9555 driver at line 817:
CONFIG_TCA64XX_INT_NCALLBACKS is a bad copy paste, should be
CONFIG_PCA9555_INT_NCALLBACKS.
After this we managed to recompile our project using the latest NuttX
sources, but it fails when trying to init the PHY irq on our STM32F427
https://github.com/apache/incubator-nuttx/issues/3769
Le 24/05/2021 à 17:36, Sebastien Lorquet a écrit :
Hello,
There is a typo in the PCA9555 driver at line 817:
CONFIG_TCA64XX_INT_NCALLBACKS is a bad copy paste, should be
CONFIG_PCA9555_INT_NCALLBACKS.
After this we managed to recompile o
On Mon, May 24, 2021 at 11:36 AM Sebastien Lorquet wrote:
>
> Hello,
>
> There is a typo in the PCA9555 driver at line 817:
> CONFIG_TCA64XX_INT_NCALLBACKS is a bad copy paste, should be
> CONFIG_PCA9555_INT_NCALLBACKS.
Good catch! Please feel free to open a PR.
> After this we managed to recomp
done, what a process for a 7-character change...
The PHY and cable detection worked perfectly fine in our project.
Sebastien
Le 24/05/2021 à 23:04, Nathan Hartman a écrit :
On Mon, May 24, 2021 at 11:36 AM Sebastien Lorquet wrote:
Hello,
There is a typo in the PCA9555 driver at line 817:
CO
On Tue, May 25, 2021 at 10:05 AM Sebastien Lorquet wrote:
>
> done, what a process for a 7-character change...
>
> The PHY and cable detection worked perfectly fine in our project.
>
> Sebastien
Thanks so much for doing that!
Regarding the process, did you have any difficulty, i.e., anything
tha
No, the workflow is very clear, the pull request model is a defacto
standard that works everywhere.
But it is heavy for trivial changes. fork, mess with remotes, make a
branch, forget to change the git config --local user.name, push, deal
with github and my ssh agent messing with multiple ssh
it will be easier next time.
Does any of the 21 queued test that I see waiting in github enable this
driver?
Because if they dont (which I suspect, hence this typo) these tests are
useless.
Sebastien
Le 25/05/2021 à 16:17, Sebastien Lorquet a écrit :
No, the workflow is very clear, the pu
On Tue, May 25, 2021 at 10:22 AM Sebastien Lorquet wrote:
>
> it will be easier next time.
Yes the workflow of git in general is a lot of steps to do a simple thing.
If you'd like to, you can still send patches to the mailing list. Just
please remember to name the file with ".txt" extension or t
Back to the business
After this we managed to recompile our project using the latest NuttX
sources, but it fails when trying to init the PHY irq on our STM32F427
board: We get "unexpected IRQ".
Yes I know that's pretty vague :-)
Is there anything obvious I should have been careful with in this
irq_unexpected_isr: ERROR irq: 3
...
My guess is that AN external IRQ is triggered (possibly not the PHY
IRQ) but the ISR handler for that one is not ready yet. I will add
debug messages.
IRQ 3 is a Hardfault, not an external IRQ or peripheral interrupt.
I would expect that situation to be
On Tue, May 25, 2021 at 12:02 PM Sebastien Lorquet
wrote:
> Back to the business
> >> After this we managed to recompile our project using the latest NuttX
> >> sources, but it fails when trying to init the PHY irq on our STM32F427
> >> board: We get "unexpected IRQ".
> >>
> >> Yes I know that's
Update: stack dump and register analysis are in fact pointing to a crash
in mm_alloc
I have enabled memory management debug:
mm_initialize: Heap: start=0x1000 size=65536
mm_addregion: Region 1: base=0x1154 size=65184
stm32_netinitialize: Enabling PHY power
stm32_netinitialize: PHY reset
If you use CONFIG_BUILD_FLAT=y, make sure that __KERNEL__ flag is set here:
https://github.com/apache/incubator-nuttx/blob/master/include/nuttx/mm/mm.h#L85
I remember that at some point I had a similar hardfault in mm which doesn't
make sense and it was due to outdated board Make.defs.
śr., 26 maj
Hello,
Thanks for the remarks.
I am using the flat (monolithic build) and I see no place that define
this flag, at all.
I dont even see a place in the codebase that defines this flag.
I see nothing related to mm, nor anything outdated in my Make.defs,
which is from my old setup, yes, but st
Maybe this one could help:
https://cwiki.apache.org/confluence/display/NUTTX/NuttX+9.1#NuttX9.1-CompatibilityConcerns
> I am using the flat (monolithic build) and I see no place that define
>this flag, at all.
>I dont even see a place in the codebase that defines this flag.
__KERNEL__ is defined
Hi Sebastien,
Stack crashing into heap?
Have you upped the stack sizes across the board?
David
-Original Message-
From: Sebastien Lorquet [mailto:sebast...@lorquet.fr]
Sent: Wednesday, May 26, 2021 9:22 AM
To: dev@nuttx.apache.org
Subject: Re: Port of project from NuttX 7.30 to 10.1
: Sebastien Lorquet [mailto:sebast...@lorquet.fr]
Sent: Wednesday, May 26, 2021 9:22 AM
To: dev@nuttx.apache.org
Subject: Re: Port of project from NuttX 7.30 to 10.1 RC1: Unexpected IRQ
Hello,
Thanks for the remarks.
I am using the flat (monolithic build) and I see no place that define
this flag, at all
Boom, that was the extrastuff. The board now boots. We're going to run a
lot of functional tests to make sure everything is okay, but I dont have
this strange hardfault at boot.
Thank you.
I did not find this page despite searching through a lot of
documentation, mainly the "official" ReadThe
I sill wonder what is the purpose of this variable rename. Sorry to say,
but it just looks cosmetic while critically breaking everything that was
made before, and this kind of thing is a nightmare for migration when
you cant follow the project day to day. Boards can be external to the
project,
I think a benefit from renaming many of those "up_something" to
"stm32_something", "esp32_something", etc is now it is easy for
software find the right function.
I think many IDEs cannot handle functions search correctly for NuttX
because they don't have heuristics to know that IF I'm searching a
I'm not talking of renaming code symbols like up_anything to
arm_anything, which makes sense and can be noticed quite easily at link
stage.
I'm talking about renaming a shell/make variable from EXTRADEFINES to
EXTRAFLAGS. This is hidden, and the build system has no way to complain
about anyth
On Fri, May 28, 2021 at 9:12 AM Sebastien Lorquet
wrote:
> I'm not talking of renaming code symbols like up_anything to
> arm_anything, which makes sense and can be noticed quite easily at link
> stage.
>
> I'm talking about renaming a shell/make variable from EXTRADEFINES to
> EXTRAFLAGS. This i
On Fri, May 28, 2021, 7:54 AM Nathan Hartman
wrote:
> On Fri, May 28, 2021 at 9:12 AM Sebastien Lorquet
> wrote:
>
> > I'm not talking of renaming code symbols like up_anything to
> > arm_anything, which makes sense and can be noticed quite easily at link
> > stage.
> >
> > I'm talking about ren
>
> We already do so much to try and not break things. If you are going to
> jump 3 major release versions that span __6 years__ you have to expect to
> run into something and should read at least the compatibility comments for
> the major releases.
>
Should have said 2 years not 6 (7.3 was 6). Bu
On Fri, May 28, 2021 at 11:43 AM Brennan Ashton
wrote:
>
> On Fri, May 28, 2021, 7:54 AM Nathan Hartman
> > 3. Make a ReleaseNotes section of the website that will render those
> > ReleaseNotes files and offer an easy to use index, so it's easier to find
> > this information. The newer ones are M
On Fri, May 28, 2021 at 11:49 AM Nathan Hartman
wrote:
>
> On Fri, May 28, 2021 at 11:43 AM Brennan Ashton
> wrote:
> >
> > On Fri, May 28, 2021, 7:54 AM Nathan Hartman
> > > 3. Make a ReleaseNotes section of the website that will render those
> > > ReleaseNotes files and offer an easy to use in
> > 2. Split up the ReleaseNotes file? As it is now, it reads a bit more like a
> > ChangeLog rather than ReleaseNotes. In the past we talked about a
> > Documentation/ReleaseNotes directory that could hold a separate
> > ReleaseNotes for each major version?
> >
> They are broken out per release an
I will try to continue testing my custom board with upcoming releases to
detect such breaks. Even if I dont get to vote in your committees I will
tell you if I find some problem.
Yes I skipped two years of nuttx development, starting christmas holiday
2019, followed by covid lockdowns and a bu
> Even if I dont get to vote in your committees I will
tell you if I find some problem.
You do get to vote, everyone can vote. It's actually helpful to have
more people voting and participating in the whole release process.
Voting for releases is done in the public dev list. PPMC members have
bi
On Fri, May 28, 2021 at 12:16 PM Sebastien Lorquet wrote:
> The documentation about NuttX is exploded all around. This is an issue
> that is often noticed by all of my colleagues that attempted to have a
> look at this project.
Documentation has moved from place to place over the years, but we ar
30 matches
Mail list logo