RE: STM32H7 serial TX DMA issues

[David Sidrane]

   Hi Kian,

   The Problem with the semaphore is it cause blocking when the port
is opened non blocking.

   Please do PR so we can review it.

David


-Original Message-
From: Kian Karas (KK) 
Sent: Friday, March 8, 2024 4:18 AM
To: dev@nuttx.apache.org
Subject: STM32H7 serial TX DMA issues

Hi community

The STM32H7 serial driver TX DMA logic is no longer working properly.

The issues started with commit 660ac63b. Subsequent attempts (f92a9068,
6c186b60) have failed to get it working again.

I think the original idea of 660ac63b is right, it just failed to restart
TX DMA upon TX DMA completion (if needed).

I would suggest reverting the following commits: 6c186b60 58f2a7b1
69a8b5b5. Then add the following patch as an amendment:

diff --git a/arch/arm/src/stm32h7/stm32_serial.c
b/arch/arm/src/stm32h7/stm32_serial.c
index 120ea0f3b5..fc90c5d521 100644
--- a/arch/arm/src/stm32h7/stm32_serial.c
+++ b/arch/arm/src/stm32h7/stm32_serial.c
@@ -3780,11 +3780,20 @@ static void up_dma_txcallback(DMA_HANDLE handle,
uint8_t status, void *arg)
 }
 }

-  nxsem_post(>txdmasem);
-
   /* Adjust the pointers */

   uart_xmitchars_done(>dev);
+
+  /* Initiate another transmit if data is ready */
+
+  if (priv->dev.xmit.tail != priv->dev.xmit.head)
+{
+  uart_xmitchars_dma(>dev);
+}
+  else
+{
+  nxsem_post(>txdmasem);
+}
 }
 #endif

@@ -3806,6 +3815,14 @@ static void up_dma_txavailable(struct uart_dev_s
*dev)
   int rv = nxsem_trywait(>txdmasem);
   if (rv == OK)
 {
+  if (dev->xmit.head == dev->xmit.tail)
+{
+  /* No data to transfer. Release semaphore. */
+
+  nxsem_post(>txdmasem);
+  return;
+}
+
   uart_xmitchars_dma(dev);
 }
 }


However, uart_xmitchars_dma() is currently not safe to call from an
interrupt service routine, so the following patch would also be required:

diff --git a/drivers/serial/serial_dma.c b/drivers/serial/serial_dma.c
index aa99e801ff..b2603953ad 100644
--- a/drivers/serial/serial_dma.c
+++ b/drivers/serial/serial_dma.c
@@ -97,26 +97,29 @@ void uart_xmitchars_dma(FAR uart_dev_t *dev)  {
   FAR struct uart_dmaxfer_s *xfer = >dmatx;

-  if (dev->xmit.head == dev->xmit.tail)
+  size_t head = dev->xmit.head;
+  size_t tail = dev->xmit.tail;
+
+  if (head == tail)
 {
   /* No data to transfer. */

   return;
 }

-  if (dev->xmit.tail < dev->xmit.head)
+  if (tail < head)
 {
-  xfer->buffer  = >xmit.buffer[dev->xmit.tail];
-  xfer->length  = dev->xmit.head - dev->xmit.tail;
+  xfer->buffer  = >xmit.buffer[tail];
+  xfer->length  = head - tail;
   xfer->nbuffer = NULL;
   xfer->nlength = 0;
 }
   else
 {
-  xfer->buffer  = >xmit.buffer[dev->xmit.tail];
-  xfer->length  = dev->xmit.size - dev->xmit.tail;
+  xfer->buffer  = >xmit.buffer[tail];
+  xfer->length  = dev->xmit.size - tail;
   xfer->nbuffer = dev->xmit.buffer;
-  xfer->nlength = dev->xmit.head;
+  xfer->nlength = head;
 }

   dev->tx_count += xfer->length + xfer->nlength;


Any thoughts?

Regards
Kian

RE: Ethernet direct RMII connection

[David Sidrane]

Rolan,

Have a look in the imx8 manual you may be able to source the clock from that
MAC.

David


-Original Message-
From: Roland 
Sent: Friday, March 1, 2024 9:55 AM
To: dev@nuttx.apache.org
Subject: Re: Ethernet direct RMII connection

Hi Alan,

Thanks for this reminder.

I am using RMII, as STM32F7 can only support up to 100MHz data rate and do
not have any GMII interface.

On imx8m side, it actually will be “downgraded” to RMII as well.

/Roland


> On Mar 1, 2024, at 9:31 PM, Alan C. Assis  wrote:
>
> Hi Roland,
>
> I think the page I sent earlier has more info about MII, RMII, RGMII,
> etc that you need to know before attempting to do it. Let me put here
> for
> clarification:
>
> "There are variants of the MII (GMII; RMII; SGMII; RGMII...) interface
> for connecting MACs to PHYs or MACs to MACs, in some of them there is
> a MAC or PHY role.
>
> The RGMII interface is a dual data rate (DDR) interface that consists
> of a transmit path and a receive path. Both paths have an independent
> clock, 4 data signals and a control signal. This means that in RGMII
> there is no PHY or MAC role, so no special support is needed for
> MAC-to-MAC connection as it is the case, being both ends in RGMII mode
> is enough for the communication to be carried out."
>
> Today I found a new page with more information and some details that
> probably will help you and others trying to do it, like clock
> shifting, otherwise it will not work:
>
> https://community.nxp.com/t5/i-MX-Processors/Direct-ETH-MAC-MII-to-MAC
> -MII-connection/m-p/1042795
>
> So, if you didn't include the clock skew circuit as shown on this
> link, then you will need to use RMII.
>
> Best Regards,
>
> Alan
>
> On Fri, Mar 1, 2024 at 8:31 AM Roland  wrote:
>
>> @Alan,
>>
>> Thanks for the hints.
>>
>> From your message I will assume that this direct mode is not
>> supported by default, so I need to start looking into it.
>>
>> I already have a basic hardware setup includes a STM32F7 custom board
>> and an imx8m custom board, all prototypes. So it would be easier for
>> me to start from these platforms @Nathan.
>>
>> As the GPIO resources are always against us, RMII would be a more
>> realistic choice to me.
>>
>> In general level I have known it is possible, as I can find some
>> successful cases in other platforms. And I will not worry too much
>> about imx8m side which running Linux, which supports direct mode
>> through RMII as claimed.
>> I will be appreciated that if any Nuttx specific
>> information/discussion about this feature that you can also share?
>> This may prevent me from wasting time on something you may already
>> explored.
>>
>> On hardware level, not sure if you can help to confirm my following
>> understanding,
>>
>> 1. MDIO pins are not mandatory, so these 2 pins are not used  on
>> current prototypes in order to save GPIOs for other purposes.
>> 2. 50MHz Reference clock is provided from a shared crystal to feed
>> into both side.
>>
>> All the best,
>> /Roland
>>
>>
>>> On Mar 1, 2024, at 3:14 AM, Alan C. Assis  wrote:
>>>
>>> Hi Roland,
>>>
>>> We had a discussion about it a few months ago!
>>>
>>> We know it is possible, but nobody until now tried to do it.
>>>
>>> Basically you will need RMII support on both chips, I don't remember
>>> the details why MII will not work (or will be more difficult to
>>> work)
>>>
>>> There is a discussion about it here, maybe you can get more insights:
>>>
>> https://stackoverflow.com/questions/39503466/can-two-ethernet-mac-chi
>> ps-be-connected-directly-without-going-thru-phy
>>>
>>> Best Regards,
>>>
>>> Alan
>>>
>>>
>>> On Thu, Feb 29, 2024 at 2:11 PM Roland  wrote:
>>>
 Hi,

 I would like to directly connect a STM32F7 processor running Nuttx,
 to
>> an
 external MCU (i.e., NXP imx8m) through RMII directly, without the
 need
>> for
 PHY IC in between.
 Is this supported by Nuttx? I checked into the documents but this
 direct mode seems not been mentioned anywhere.
 Can anyone please confirm if this is supported, or I have to change
 something by myself?

 Thank you.

 /Roland


>>
>>

RE: IMXRT: LPUART IDLE character Kconfig setting request

[David Sidrane]

What about adding it per [LP]U[S]ART in the Kconfig here
https://github.com/apache/nuttx/tree/master/drivers/serial

Then any arch can use it.

David

-Original Message-
From: Daniel Appiagyei 
Sent: Monday, October 9, 2023 12:51 AM
To: dev@nuttx.apache.org
Subject: IMXRT: LPUART IDLE character Kconfig setting request

Hi,
The IMXRT's LPUARTs have support for configuring the number of idle
characters it receives over UART before setting the STAT register's IDLE
flag. The setting is in CTRL[IDLECFG].
Are anyone imxrt users already planning to add support for this in master?
I will do so if not.
Will place the appropriate configs in
https://github.com/apache/nuttx/blob/master/arch/arm/src/imxrt/Kconfig

Best,

Daniel

RE: iMXRT usbdev endpoint allocation problem

[David Sidrane]

Hi Marten ,

See https://github.com/apache/nuttx/pull/4784

Furthermore once all the caching was working, the USB driver had a bug
that the bulk endpoints was getting confused with the interrupt endpoints
and although sized to 512 where reporting a max size of 1024 causing more
fun memory overwrites.

So it was because of memory overwrites.

How would you suggest it be changed?

David

-Original Message-
From: Mårten Svanfeldt 
Sent: Friday, September 15, 2023 4:23 AM
To: dev@nuttx.apache.org
Subject: iMXRT usbdev endpoint allocation problem

Hi,


I'm in the process of updating our internal NuttX from version 10.1 to
12.2.1, and ran into some issues with usb device code on iMXRT.


We have a device that exposes a custom class with a fixed endpoint mapping
(the toolstack in the other end expects certain endpoint mappings, using
ep1 and ep2 for bulk transfers), and I can make it work again by reverting
the following commit
https://github.com/apache/nuttx/commit/c077361a8a9fc9182b988dee7224043022e
ea841


>From a theoretical standpoint I don't understand why that commit was ever
made. The USB controller in iMXRT10xx series, which is same as in other
iMX chips (iMX6 for example) has no limitations of that certain endpoints
needs to map to interrupt/bulk/iso, so I would suggest that the change
itself is actually wrong and should be reverted upstream. Does anyone have
any more background on the change, the git commit message is very terse...


Regards

Marten Svanfeldt

RE: Addition of STM32H7 MCU's

[David Sidrane]

The way to fix it is to fully name the files that are *different* by
replacing the x with the part number’s digit E.G.  stm32h7x3xx_irq.h ->
stm32h723xx_irq.h

The top level inclusion file will have the ifdef logic to include the
correct part based on chip selection: See



https://github.com/apache/nuttx/blob/master/arch/arm/include/stm32h7/irq.h#L70-L84



Even if it duplicates 90% of the file it is better than #ifdefing the
stm32h7x3xx_irq.h file. AKA ifdef rash!



David



*From:* o.svezhins...@indrones.ru.INVALID 

*Sent:* Friday, September 8, 2023 5:16 AM
*To:* dev@nuttx.apache.org
*Subject:* Addition of STM32H7 MCU's



Hi, all

I would like to start working on developing support for STM32H735
microcontrollers in NuttX OS, but I found some strange things in the
principle of configuring this series of microcontrollers.

Microcontrollers of the H7 series are divided into several subseries, each
united by one reference manual:
- STM32H723/733, STM32H725/735 and STM32H730 (RM0468)
- STM32H745/755 and STM32H747/757 (RM0399)
- STM32H742, STM32H743/753 and STM32H750 (RM0433)
- STM32H7A3/7B3 and STM32H7B0 (RM0455)

But some header files in arch/arm/include/stm32h7 are designated as
stm32h7x3xx_irq.h or stm32h7x5xx_irq.h, although they are only for the H743
or H745 series respectively, not for H723 or H735. And such a discrepancy
is also present in other source code files that belong to the H7 series.

Maybe it's worth fixing this somehow? Will this break anything important?


Oleg Svezhinskiy

RE: CAN TX fail handling

[David Sidrane]

Tim,

See https://github.com/apache/nuttx/issues/3927

David

-Original Message-
From: Alan C. Assis 
Sent: Wednesday, August 9, 2023 3:47 PM
To: dev@nuttx.apache.org
Cc: Pavel Pisa 
Subject: Re: CAN TX fail handling

Hi Tim,

Agree! This behavior could be implemented in the driver, for example using
some elapsed time. But again, it needs to be analyzed careful to avoid
introduce sometime too specific for a user needs.

Currently the can_close() try to wait for the TX complete that could never
happen because this issue.

If you implement the idea of resetting the CAN controller in the
can_close() you need to guarantee that it will be reinitialized correctly,
because in can_open() it expects the CAN controller in working state.

BR,

Alan

On 8/9/23, Tim Hardisty  wrote:
> Thanks Alan,
>
> I can see that a timeout/retry in detail would be hardware dependent.
> But in the absence of "something," code can send a message, but have
> no idea that it hasn't actually been sent, then try and close the "file"
> and the thread will hang indefinitely. I think we need something that
> reports the fail so some kind of recovery/reset can be attempted?
>
> Perhaps the "close" could be wrapped with something to deal with this?
> Or the open mode needs to be different somehow?
>
> POSIX/Linux type programming is new to me, after decades of bare-metal
> type software dev where I'm in total control albeit unique to a
> given/chosen processor, so any suggestions would be very welcome.
>
> On 09/08/2023 19:56, Alan C. Assis wrote:
>> Hi Tim,
>>
>> I think that the default behavior of CAN Controller is trying to send
>> indefinitely a message, some HW can define some retry limit.
>>
>> Please take a look:
>> https://forum.pjrc.com/threads/67435-FlexCAN-Infinite-Endless-TX-Retr
>> ies
>>
>> So, I'm not sure if it will make sense to implement a CAN TX timeout
>> on NuttX side, since this behavior could be HW dependent.
>>
>> BR,
>>
>> Alan
>>
>> On 8/9/23, Tim Hardisty  wrote:
>>> I am now cracking on with the app for my custom board, and in
>>> parallel writing a production board-test app.
>>>
>>> In trying to cover potential board faults, I have found that if
>>> there's something that prevents a CAN message reaching an
>>> endpoint/destination, the CAN transmitter (of course, as I
>>> understand it) is continuously retrying the message send, meaning
>>> the test app hangs when you try and close the file once the test has
>>> been deemed to fail. That is "by design" in the higher (i.e.
>>> non-arch specific) can code as it waits for the TX FIFO/queue to empty
>>> until the close is allowed.
>>>
>>> What is the correct POSIX way to handle this error condition?
>>>
>>> Might it be better to use Socket CAN, for example, assuming it has
>>> better error handling by design, or is the NuttX CAN "system"
>>> fundamentally missing something to handle this (or, more likely,
>>> I've just missed it )?
>>>
>>>
> --
>
> Regards,
>
> Tim Hardisty
>
>
> A picture containing text, clipart Description automatically generated
>
>
>
> +44 (0) 1305 534535
>
>
>
> 
>
>
>
> JTi.uk.com 
>
>
>
> 
>
>
>
> \JTinnovations 
>
> JT Innovations Ltd.
>
> Registered office: 36 East St, Weymouth, Dorset, DT3 4DT, UK.
>
> Company number 7619086
>
> VAT Registration GB 111 7906 35
>

RE: SD and eMMC performance in Nuttx

[David Sidrane]

Hi Radek Pesina,

This may be way off base but, have you tried reverting
https://github.com/apache/nuttx/commit/7312a553bbc40f3771c5d53ccded89bed7391f2a

It release the CPU but traded that for potentially quantized large delays

David

-Original Message-
From: Radek Pesina 
Sent: Wednesday, May 31, 2023 3:11 AM
To: dev@nuttx.apache.org
Subject: Re: SD and eMMC performance in Nuttx

Hi Nathan,

Thanks for the reply.  The round-robin interval was set to 200ms and
reducing it down to 10 marginally improved the transfer speed.  Our current
code base and dev board is running a slightly quicker clock than what I used
when I measured 75KiB/s, and the current setup is transferring at 100KiB/s
with a RR interval of 200 and this increases to 135KiB/s with a RR interval
of 10ms.

Yes I do have access to an oscilloscope and logic analyzer so will endeavour
to obtain some traces tomorrow to rule in/out possible unexpected delays
and/or noise.

*Kind regards,*

*Radek Pesina*

On Wed, 31 May 2023 at 11:33, Nathan Hartman 
wrote:

> On Tue, May 30, 2023 at 8:07 PM Radek Pesina
> 
> wrote:
>
> (snip)
>
>  *Configurations Tested:*
> >
> > For eMMC, I've tried optimising the menuconfig settings to improve it,
> > including options such as below.   However, the performance remains
> > lacking:
> >
> >- Turning on CONFIG_MEMCPY_VIK gave slight improvement
> >- Setting USEC_PER_TICK to 1000 or below gave most improvement,
> however
> >at the detriment of other aspects of the system. The fastest speeds
> >observed by adjusting this was ~370KiB/s write and 700KiB/s read
> though
> >overall this was unacceptable given the effect on the rest of the
> > system.
> >- Adjusting LittleFS parameters (e.g.
> >CONFIG_FS_LITTLEFS_PROGRAM_SIZE_FACTOR,
> >CONFIG_FS_LITTLEFS_READ_SIZE_FACTOR,
> > CONFIG_FS_LITTLEFS_BLOCK_SIZE_FACTOR,
> >CONFIG_FS_LITTLEFS_CACHE_SIZE_FACTOR,
> CONFIG_FS_LITTLEFS_LOOKAHEAD_SIZE
> >- Ensuring SD/eMMC DMA read/writes are enabled.
> >- Setting MMCSD_MULTIBLOCK_LIMIT to 0
> >
>
> (snip)
>
> Out of curiosity, what is the value of CONFIG_RR_INTERVAL, and, if you
> reduce it to something like 20 or 10, does that show any improvement?
>
> Do you have an oscilloscope or logic analyzer available to monitor the
> signals between the microcontroller and MMC? That might shed
> additional light on this. E.g., extremely noisy signals, intermittent
> signals, unexpectedly long delays between bursts of communication, etc.
>
> Nathan
>

RE: How ro re-trigger CI workflow?

[David Sidrane]

Close and reopen PR or rebase on master and force push the branch.

The latter is preferable if the CI fix was on master

-Original Message-
From: fft 
Sent: Saturday, April 22, 2023 4:25 AM
To: dev 
Subject: How ro re-trigger CI workflow?

Hello,


Two weeks ago, i created a PR #8999 to fix an issue of mpu60x0 drivers in
SPI mode, but the PR was hanged due to nuttx's CI broken. it seems that the
nuttx's CI was fixed by #9036 recently, but i don't know how to re-trigger
CI workflow of PR #8999, I checked Github webpage, there's no button to
re-trigger CI workflow, I searched online and there no answer as well.
anyone who can give me some suggestion?



Best regards,
Zou

RE: Hardcoded Pin mux, pad control and Drive Strength (AKA Slew-rate and Frequency) Settings #1570

[David Sidrane]

The PR to make these changes is here
https://github.com/apache/nuttx/pull/8992

There is a tool that will provide you with the changes that are needed in
the board.h

2 boards have been converted to provide examples of the conversion of the
different pinmaps types (STM32F1 series is different that all the stm32)

board olimexino-stm32:Rework board.h not use CONFIG_STM32_USE_LEGACY_PINMAP

board nucleo-h743zi:Rework board.h not use CONFIG_STM32_USE_LEGACY_PINMAP

Please have a look at the PR and test any out of tree boards you may have so
that we may bring this in soon.

Thank you,

David

-Original Message-
From: David Sidrane 
Sent: Wednesday, April 12, 2023 2:49 AM
To: 'dev@nuttx.apache.org' 
Subject: RE: Hardcoded Pin mux, pad control and Drive Strength (AKA
Slew-rate and Frequency) Settings #1570

Nathan, no worries. I ended up doing the STM32G families yesterday.

David



-Original Message-
From: Nathan Hartman 
Sent: Tuesday, April 11, 2023 10:40 PM
To: dev@nuttx.apache.org
Subject: Re: Hardcoded Pin mux, pad control and Drive Strength (AKA
Slew-rate and Frequency) Settings #1570

@davids5, I saw the request on GitHub for help with the STM32G families but
unfortunately something has come up and I won't be able to work on it this
week. Hopefully someone else can volunteer, otherwise I'll try to help next
week...

Thanks,
Nathan

On Tue, Apr 11, 2023 at 7:58 AM David Sidrane 
wrote:

> @slorquet Please have a look at #8992. Let me know if it addresses all
> the concerns you have.
>
> -Original Message-
> From: Sebastien Lorquet 
> Sent: Friday, April 7, 2023 9:58 AM
> To: dev@nuttx.apache.org
> Subject: Re: Hardcoded Pin mux, pad control and Drive Strength (AKA
> Slew-rate and Frequency) Settings #1570
>
> Thanks for the notification.
>
> Your proposal is mostly OK for me, I hope others will send reactions
> too. I have just one concern.
>
>
> If I attempt to rephrase the proposal: Starting from a commit in a
> future, stm32h7 GPIO definitions will not include speed indications
> anymore, and these will have to be added manually in board.h, but ONLY
> if the LEGACY_PINMAP is not set?
>
>
> Here is my concern: What will happen if a user (me, probably) builds a
> NuttX with this new commit from a full stored defconfig, but does not
> regenerate its config prior to rebuilding ? the LEGACY_PINMAP setting
> will not be present when building in that case.
>
> Can we force a config update before starting the build, so the
> LEGACY_PINMAP setting will be set to Y automatically in all cases?
>
>
> Also, this has to be documented very clearly, not just the official
> release notes for the next release!
>
> Aditionnally, if LEGACY_PINMAP is set in user config, maybe we can add
> a compile time warning in stm32h7/stm32_gpio.c that in the future,
> users are required to update their board.h and once done, disable
> LEGACY_PINMAP ?
>
> Sebastien
>
>
> Le 07/04/2023 à 15:34, David Sidrane a écrit :
> > Opening the discussion for this issue on the list. See
> > https://github.com/apache/nuttx/issues/1570
> >
> >
> >
> > I would like to get feedback on the approach see if we can move
> > forward
> on
> > this.
> >
> >
> >
> >
> >
> > While some solutions were discussed in
> >
> > - Revert "stm32h7 sdmmc: set SDMMC_CK pin to high speed (50 MHz)
> > mode."
> >  #5012 <https://github.com/apache/nuttx/pull/5012>
> >
> > I would like to propose a solution for this issue as a request for
> > comment:
> >
> > 1. That will not affect any existing boards
> > 2. Will allow us to fix the issues without forcing massive changes.
> > 3. Eventually after N more releases of NuttX deprecate the solution.
> >
> > Steps to get there:
> >
> > 1. Kconfig for all effected arches will have
> > STM32xxx_USE_LEGACY_PINMAP
> > set to yes as a default.
> > 2. Rework top level pinmap files E.G. hardware/stm32_pinmap.h.
> > 3. The current pinmap file will be renamed with _legacy E.G.
> > hardware/stm32h7x3xx_pinmap_legacy.h
> > 4. Rework chip specific files removing speeds and adding _0 to the
> > previous no-selectable pins with speeds
> > 5. Rework chip specific files adding _0 to the previous
> > no-selectable
> > pins
> >
> > The hardware/stm32_pinmap.h will have the following structure
> >
> > #if defined(STM32H7_USE_LEGACY_PINMAP )
> >
> > #  if defined(CONFIG_STM32H7_STM32H7X3XX)
> >
> > #include "hardware/stm32h7x3xx_pinmap_legacy.h"
> >
> > #  elif defined(CONFIG_STM32H7_STM32H7X7XX)
> >
> > 

RE: Hardcoded Pin mux, pad control and Drive Strength (AKA Slew-rate and Frequency) Settings #1570

[David Sidrane]

Nathan, no worries. I ended up doing the STM32G families yesterday.

David



-Original Message-
From: Nathan Hartman 
Sent: Tuesday, April 11, 2023 10:40 PM
To: dev@nuttx.apache.org
Subject: Re: Hardcoded Pin mux, pad control and Drive Strength (AKA
Slew-rate and Frequency) Settings #1570

@davids5, I saw the request on GitHub for help with the STM32G families but
unfortunately something has come up and I won't be able to work on it this
week. Hopefully someone else can volunteer, otherwise I'll try to help next
week...

Thanks,
Nathan

On Tue, Apr 11, 2023 at 7:58 AM David Sidrane 
wrote:

> @slorquet Please have a look at #8992. Let me know if it addresses all
> the concerns you have.
>
> -Original Message-
> From: Sebastien Lorquet 
> Sent: Friday, April 7, 2023 9:58 AM
> To: dev@nuttx.apache.org
> Subject: Re: Hardcoded Pin mux, pad control and Drive Strength (AKA
> Slew-rate and Frequency) Settings #1570
>
> Thanks for the notification.
>
> Your proposal is mostly OK for me, I hope others will send reactions
> too. I have just one concern.
>
>
> If I attempt to rephrase the proposal: Starting from a commit in a
> future, stm32h7 GPIO definitions will not include speed indications
> anymore, and these will have to be added manually in board.h, but ONLY
> if the LEGACY_PINMAP is not set?
>
>
> Here is my concern: What will happen if a user (me, probably) builds a
> NuttX with this new commit from a full stored defconfig, but does not
> regenerate its config prior to rebuilding ? the LEGACY_PINMAP setting
> will not be present when building in that case.
>
> Can we force a config update before starting the build, so the
> LEGACY_PINMAP setting will be set to Y automatically in all cases?
>
>
> Also, this has to be documented very clearly, not just the official
> release notes for the next release!
>
> Aditionnally, if LEGACY_PINMAP is set in user config, maybe we can add
> a compile time warning in stm32h7/stm32_gpio.c that in the future,
> users are required to update their board.h and once done, disable
> LEGACY_PINMAP ?
>
> Sebastien
>
>
> Le 07/04/2023 à 15:34, David Sidrane a écrit :
> > Opening the discussion for this issue on the list. See
> > https://github.com/apache/nuttx/issues/1570
> >
> >
> >
> > I would like to get feedback on the approach see if we can move
> > forward
> on
> > this.
> >
> >
> >
> >
> >
> > While some solutions were discussed in
> >
> > - Revert "stm32h7 sdmmc: set SDMMC_CK pin to high speed (50 MHz)
> > mode."
> >  #5012 <https://github.com/apache/nuttx/pull/5012>
> >
> > I would like to propose a solution for this issue as a request for
> > comment:
> >
> > 1. That will not affect any existing boards
> > 2. Will allow us to fix the issues without forcing massive changes.
> > 3. Eventually after N more releases of NuttX deprecate the solution.
> >
> > Steps to get there:
> >
> > 1. Kconfig for all effected arches will have
> > STM32xxx_USE_LEGACY_PINMAP
> > set to yes as a default.
> > 2. Rework top level pinmap files E.G. hardware/stm32_pinmap.h.
> > 3. The current pinmap file will be renamed with _legacy E.G.
> > hardware/stm32h7x3xx_pinmap_legacy.h
> > 4. Rework chip specific files removing speeds and adding _0 to the
> > previous no-selectable pins with speeds
> > 5. Rework chip specific files adding _0 to the previous
> > no-selectable
> > pins
> >
> > The hardware/stm32_pinmap.h will have the following structure
> >
> > #if defined(STM32H7_USE_LEGACY_PINMAP )
> >
> > #  if defined(CONFIG_STM32H7_STM32H7X3XX)
> >
> > #include "hardware/stm32h7x3xx_pinmap_legacy.h"
> >
> > #  elif defined(CONFIG_STM32H7_STM32H7X7XX)
> >
> > #include "hardware/stm32h7x3xx_pinmap_legacy.h"
> >
> > #  else
> >
> > # error "Unsupported STM32 H7 Legacy Pin map"
> >
> > #  endif
> >
> > #else
> >
> > #  if defined(CONFIG_STM32H7_STM32H7X3XX)
> >
> > #include "hardware/stm32h7x3xx_pinmap.h"
> >
> > #  elif defined(CONFIG_STM32H7_STM32H7X7XX)
> >
> > #include "hardware/stm32h7x3xx_pinmap.h"
> >
> > #  else
> >
> > # error "Unsupported STM32 H7 Pin map"
> >
> > #  endif
> >
> > # endif
> >
> >
> >
> > Moving forward boards will turn off STM32xx_USE_LEGACY_PINMAP and
> > update the board.h files to fully def

RE: Hardcoded Pin mux, pad control and Drive Strength (AKA Slew-rate and Frequency) Settings #1570

[David Sidrane]

@slorquet Please have a look at #8992. Let me know if it addresses all the
concerns you have.

-Original Message-
From: Sebastien Lorquet 
Sent: Friday, April 7, 2023 9:58 AM
To: dev@nuttx.apache.org
Subject: Re: Hardcoded Pin mux, pad control and Drive Strength (AKA
Slew-rate and Frequency) Settings #1570

Thanks for the notification.

Your proposal is mostly OK for me, I hope others will send reactions too. I
have just one concern.


If I attempt to rephrase the proposal: Starting from a commit in a
future, stm32h7 GPIO definitions will not include speed indications
anymore, and these will have to be added manually in board.h, but ONLY
if the LEGACY_PINMAP is not set?


Here is my concern: What will happen if a user (me, probably) builds a
NuttX with this new commit from a full stored defconfig, but does not
regenerate its config prior to rebuilding ? the LEGACY_PINMAP setting
will not be present when building in that case.

Can we force a config update before starting the build, so the
LEGACY_PINMAP setting will be set to Y automatically in all cases?


Also, this has to be documented very clearly, not just the official
release notes for the next release!

Aditionnally, if LEGACY_PINMAP is set in user config, maybe we can add a
compile time warning in stm32h7/stm32_gpio.c that in the future, users
are required to update their board.h and once done, disable LEGACY_PINMAP ?

Sebastien


Le 07/04/2023 à 15:34, David Sidrane a écrit :
> Opening the discussion for this issue on the list. See
> https://github.com/apache/nuttx/issues/1570
>
>
>
> I would like to get feedback on the approach see if we can move forward on
> this.
>
>
>
>
>
> While some solutions were discussed in
>
> - Revert "stm32h7 sdmmc: set SDMMC_CK pin to high speed (50 MHz)
> mode."
>  #5012 <https://github.com/apache/nuttx/pull/5012>
>
> I would like to propose a solution for this issue as a request for
> comment:
>
> 1. That will not affect any existing boards
> 2. Will allow us to fix the issues without forcing massive changes.
> 3. Eventually after N more releases of NuttX deprecate the solution.
>
> Steps to get there:
>
> 1. Kconfig for all effected arches will have
> STM32xxx_USE_LEGACY_PINMAP
> set to yes as a default.
> 2. Rework top level pinmap files E.G. hardware/stm32_pinmap.h.
> 3. The current pinmap file will be renamed with _legacy E.G.
> hardware/stm32h7x3xx_pinmap_legacy.h
> 4. Rework chip specific files removing speeds and adding _0 to the
> previous no-selectable pins with speeds
> 5. Rework chip specific files adding _0 to the previous no-selectable
> pins
>
> The hardware/stm32_pinmap.h will have the following structure
>
> #if defined(STM32H7_USE_LEGACY_PINMAP )
>
> #  if defined(CONFIG_STM32H7_STM32H7X3XX)
>
> #include "hardware/stm32h7x3xx_pinmap_legacy.h"
>
> #  elif defined(CONFIG_STM32H7_STM32H7X7XX)
>
> #include "hardware/stm32h7x3xx_pinmap_legacy.h"
>
> #  else
>
> # error "Unsupported STM32 H7 Legacy Pin map"
>
> #  endif
>
> #else
>
> #  if defined(CONFIG_STM32H7_STM32H7X3XX)
>
> #include "hardware/stm32h7x3xx_pinmap.h"
>
> #  elif defined(CONFIG_STM32H7_STM32H7X7XX)
>
> #include "hardware/stm32h7x3xx_pinmap.h"
>
> #  else
>
> # error "Unsupported STM32 H7 Pin map"
>
> #  endif
>
> # endif
>
>
>
> Moving forward boards will turn off STM32xx_USE_LEGACY_PINMAP and update
> the board.h files to fully define
> the pins with selected speeds.
>
> was:
>
> #define GPIO_SDMMC2_CK   GPIO_SDMMC2_CK_1  /* PD6  FC_PD6_SDMMC2_CK  */
>
> #define GPIO_SDMMC2_CMD  GPIO_SDMMC2_CMD_1 /* PD7  FC_PD7_SDMMC2_CMD */
>
> //  GPIO_SDMMC2_D0   No Remap  /* PB14 FC_PB14_SDMMC2_D0 */
>
> //  GPIO_SDMMC2_D1   No Remap  /* PB15 FC_PB15_SDMMC2_D1 */
>
> #define GPIO_SDMMC2_D2   GPIO_SDMMC2_D2_1  /* PG11 FC_PG11_SDMMC2_D2 */
>
> //  GPIO_SDMMC2_D3No Remap /* PB4  FC_PB4_SDMMC2_D3  */
>
> is:
>
> #define GPIO_SDMMC2_CK   (GPIO_SDMMC2_CK_1|  GPIO_SPEED_25MHz)  /*
> PD6  FC_PD6_SDMMC2_CK  */
>
> #define GPIO_SDMMC2_CMD  (GPIO_SDMMC2_CMD_1 |  GPIO_SPEED_2MHz)  /*
> PD7  FC_PD7_SDMMC2_CMD */
>
> #define GPIO_SDMMC2_D0   (GPIO_SDMMC2_D0_0  | GPIO_SPEED_2MHz) /* PB14
> FC_PB14_SDMMC2_D0 */
>
> #define GPIO_SDMMC2_D1   (GPIO_SDMMC2_D1_0  |  GPIO_SPEED_2MHz)/* PB15
> FC_PB15_SDMMC2_D1 */
>
> #define GPIO_SDMMC2_D2GPIO_SDMMC2_D2_1  | GPIO_SPEED_2MHz)  /*
> PG11 FC_PG11_SDMMC2_D2 */
>
> #define GPIO_SDMMC2_D3   (GPIO_SDMMC2_D3_0  | GPIO_SPEED_2MHz) /* PB4
> FC_PB4_SDMMC2_D3  */
>
>
>
> To maintain the speed that was set in the legacy files just diff the
> _legacy file
> with the non legacy file and use that
> speed when creating the #define.
>

RE: Hardcoded Pin mux, pad control and Drive Strength (AKA Slew-rate and Frequency) Settings #1570

[David Sidrane]

-Original Message-
From: Frank-Christian Kruegel 
Sent: Monday, April 10, 2023 9:01 AM
To: dev@nuttx.apache.org
Subject: Re: Hardcoded Pin mux, pad control and Drive Strength (AKA
Slew-rate and Frequency) Settings #1570

Am 10.04.2023 um 14:51 schrieb David Sidrane:

> If I attempt to rephrase the proposal: Starting from a commit in a
> future, stm32h7 GPIO definitions will not include speed indications
> anymore, and these will have to be added manually in board.h, but ONLY
> if the LEGACY_PINMAP is not set?
> [DBS] Yes. This is correct. But also previously non suffixed pin. E.G.
> Where there were not ALT settings to choose which GPIO to use will
> contain a _0 suffix.

I've designed several custom boards where I can put in an STM32F4, STM32F7,
or STM32H7 depending on chip availability and performance needs. I've got
board support packages for each family and keep them in sync so I can
deliver what is needed.

My main concern and my loudest plea is: Please keep stm32f4, stm32f7, and
stm32h7 in sync. For me making changes that make sense and pay off in the
future are ok, but please make them on all stm32 families (at least the big
ones).

[
[DBS] Please have a look at https://github.com/apache/nuttx/pull/8992 and
see if that is in sync or if it misses something.


Frank-Christian Kruegel

RE: Hardcoded Pin mux, pad control and Drive Strength (AKA Slew-rate and Frequency) Settings #1570

[David Sidrane]

-Original Message-
From: Sebastien Lorquet 
Sent: Friday, April 7, 2023 9:58 AM
To: dev@nuttx.apache.org
Subject: Re: Hardcoded Pin mux, pad control and Drive Strength (AKA
Slew-rate and Frequency) Settings #1570

Thanks for the notification.
[DBS] Thank you for your response.

Your proposal is mostly OK for me, I hope others will send reactions too. I
have just one concern.


If I attempt to rephrase the proposal: Starting from a commit in a
future, stm32h7 GPIO definitions will not include speed indications
anymore, and these will have to be added manually in board.h, but ONLY
if the LEGACY_PINMAP is not set?
[DBS] Yes. This is correct. But also previously non suffixed pin. E.G. Where
there were not ALT settings to choose which GPIO to use will contain a _0
suffix.


Here is my concern: What will happen if a user (me, probably) builds a
NuttX with this new commit from a full stored defconfig, but does not
regenerate its config prior to rebuilding ? the LEGACY_PINMAP setting
will not be present when building in that case.
[DBS] Correct, but one should always run 'make oldconfig' when changing
versions of NuttX.
If you do not do this. Then the compile will fail with errors that resemble

chip/stm32_serial.c:1231:20: error: 'GPIO_UART5_CTS' undeclared here (not in
a function); did you mean 'GPIO_UART7_CTS'?

 1231 |   .cts_gpio  = GPIO_UART5_CTS,

  |^~

  |GPIO_UART7_CTS

chip/stm32_serial.c:1235:20: error: 'GPIO_UART5_RTS' undeclared here (not in
a function); did you mean 'GPIO_UART7_RTS'?

 1235 |   .rts_gpio  = GPIO_UART5_RTS,

  |^~

  |GPIO_UART7_RTS


Can we force a config update before starting the build, so the
LEGACY_PINMAP setting will be set to Y automatically in all cases?
[DBS] Yes `make oldconfig`


Also, this has to be documented very clearly, not just the official
release notes for the next release!
[DBS] Yes. I have created a tool. It will update the pinmaps, create a
legacy map and given a board.h
Will tell you what to add/change.

Aditionnally, if LEGACY_PINMAP is set in user config, maybe we can add a
compile time warning in stm32h7/stm32_gpio.c that in the future, users
are required to update their board.h and once done, disable LEGACY_PINMAP ?
[DBS] We can do this with a message pragma, so as not to kill CI.


Sebastien


Le 07/04/2023 à 15:34, David Sidrane a écrit :
> Opening the discussion for this issue on the list. See
> https://github.com/apache/nuttx/issues/1570
>
>
>
> I would like to get feedback on the approach see if we can move forward on
> this.
>
>
>
>
>
> While some solutions were discussed in
>
> - Revert "stm32h7 sdmmc: set SDMMC_CK pin to high speed (50 MHz)
> mode."
>  #5012 <https://github.com/apache/nuttx/pull/5012>
>
> I would like to propose a solution for this issue as a request for
> comment:
>
> 1. That will not affect any existing boards
> 2. Will allow us to fix the issues without forcing massive changes.
> 3. Eventually after N more releases of NuttX deprecate the solution.
>
> Steps to get there:
>
> 1. Kconfig for all effected arches will have
> STM32xxx_USE_LEGACY_PINMAP
> set to yes as a default.
> 2. Rework top level pinmap files E.G. hardware/stm32_pinmap.h.
> 3. The current pinmap file will be renamed with _legacy E.G.
> hardware/stm32h7x3xx_pinmap_legacy.h
> 4. Rework chip specific files removing speeds and adding _0 to the
> previous no-selectable pins with speeds
> 5. Rework chip specific files adding _0 to the previous no-selectable
> pins
>
> The hardware/stm32_pinmap.h will have the following structure
>
> #if defined(STM32H7_USE_LEGACY_PINMAP )
>
> #  if defined(CONFIG_STM32H7_STM32H7X3XX)
>
> #include "hardware/stm32h7x3xx_pinmap_legacy.h"
>
> #  elif defined(CONFIG_STM32H7_STM32H7X7XX)
>
> #include "hardware/stm32h7x3xx_pinmap_legacy.h"
>
> #  else
>
> # error "Unsupported STM32 H7 Legacy Pin map"
>
> #  endif
>
> #else
>
> #  if defined(CONFIG_STM32H7_STM32H7X3XX)
>
> #include "hardware/stm32h7x3xx_pinmap.h"
>
> #  elif defined(CONFIG_STM32H7_STM32H7X7XX)
>
> #include "hardware/stm32h7x3xx_pinmap.h"
>
> #  else
>
> # error "Unsupported STM32 H7 Pin map"
>
> #  endif
>
> # endif
>
>
>
> Moving forward boards will turn off STM32xx_USE_LEGACY_PINMAP and update
> the board.h files to fully define
> the pins with selected speeds.
>
> was:
>
> #define GPIO_SDMMC2_CK   GPIO_SDMMC2_CK_1  /* PD6  FC_PD6_SDMMC2_CK  */
>
> #define GPIO_SDMMC2_CMD  GPIO_SDMMC2_CMD_1 /* PD7  FC_PD7_SDMMC2_CMD */
>
&g

Hardcoded Pin mux, pad control and Drive Strength (AKA Slew-rate and Frequency) Settings #1570

[David Sidrane]

Opening the discussion for this issue on the list. See
https://github.com/apache/nuttx/issues/1570



I would like to get feedback on the approach see if we can move forward on
this.





While some solutions were discussed in

   - Revert "stm32h7 sdmmc: set SDMMC_CK pin to high speed (50 MHz) mode."
#5012 

I would like to propose a solution for this issue as a request for comment:

   1. That will not affect any existing boards
   2. Will allow us to fix the issues without forcing massive changes.
   3. Eventually after N more releases of NuttX deprecate the solution.

Steps to get there:

   1. Kconfig for all effected arches will have STM32xxx_USE_LEGACY_PINMAP
   set to yes as a default.
   2. Rework top level pinmap files E.G. hardware/stm32_pinmap.h.
   3. The current pinmap file will be renamed with _legacy E.G.
   hardware/stm32h7x3xx_pinmap_legacy.h
   4. Rework chip specific files removing speeds and adding _0 to the
   previous no-selectable pins with speeds
   5. Rework chip specific files adding _0 to the previous no-selectable
   pins

The hardware/stm32_pinmap.h will have the following structure

#if defined(STM32H7_USE_LEGACY_PINMAP )

#  if defined(CONFIG_STM32H7_STM32H7X3XX)

#include "hardware/stm32h7x3xx_pinmap_legacy.h"

#  elif defined(CONFIG_STM32H7_STM32H7X7XX)

#include "hardware/stm32h7x3xx_pinmap_legacy.h"

#  else

# error "Unsupported STM32 H7 Legacy Pin map"

#  endif

#else

#  if defined(CONFIG_STM32H7_STM32H7X3XX)

#include "hardware/stm32h7x3xx_pinmap.h"

#  elif defined(CONFIG_STM32H7_STM32H7X7XX)

#include "hardware/stm32h7x3xx_pinmap.h"

#  else

# error "Unsupported STM32 H7 Pin map"

#  endif

# endif



Moving forward boards will turn off STM32xx_USE_LEGACY_PINMAP and update
the board.h files to fully define
the pins with selected speeds.

was:

#define GPIO_SDMMC2_CK   GPIO_SDMMC2_CK_1  /* PD6  FC_PD6_SDMMC2_CK  */

#define GPIO_SDMMC2_CMD  GPIO_SDMMC2_CMD_1 /* PD7  FC_PD7_SDMMC2_CMD */

//  GPIO_SDMMC2_D0   No Remap  /* PB14 FC_PB14_SDMMC2_D0 */

//  GPIO_SDMMC2_D1   No Remap  /* PB15 FC_PB15_SDMMC2_D1 */

#define GPIO_SDMMC2_D2   GPIO_SDMMC2_D2_1  /* PG11 FC_PG11_SDMMC2_D2 */

//  GPIO_SDMMC2_D3No Remap /* PB4  FC_PB4_SDMMC2_D3  */

is:

#define GPIO_SDMMC2_CK   (GPIO_SDMMC2_CK_1|  GPIO_SPEED_25MHz)  /*
PD6  FC_PD6_SDMMC2_CK  */

#define GPIO_SDMMC2_CMD  (GPIO_SDMMC2_CMD_1 |  GPIO_SPEED_2MHz)  /*
PD7  FC_PD7_SDMMC2_CMD */

#define GPIO_SDMMC2_D0   (GPIO_SDMMC2_D0_0  | GPIO_SPEED_2MHz) /* PB14
FC_PB14_SDMMC2_D0 */

#define GPIO_SDMMC2_D1   (GPIO_SDMMC2_D1_0  |  GPIO_SPEED_2MHz)/* PB15
FC_PB15_SDMMC2_D1 */

#define GPIO_SDMMC2_D2GPIO_SDMMC2_D2_1  | GPIO_SPEED_2MHz)  /*
PG11 FC_PG11_SDMMC2_D2 */

#define GPIO_SDMMC2_D3   (GPIO_SDMMC2_D3_0  | GPIO_SPEED_2MHz) /* PB4
FC_PB4_SDMMC2_D3  */



To maintain the speed that was set in the legacy files just diff the
_legacy file
with the non legacy file and use that
speed when creating the #define.

RE: DISCUSSION - Usage of mailing lists for apache projects

[David Sidrane]

+1 100%

I think that the PR should have a summary as well to ensure it is all tied
together. Unless we enable rebase/squash the information will be disjoint.

David


-Original Message-
From: alin.jerpe...@sony.com 
Sent: Thursday, March 9, 2023 4:13 AM
To: dev@nuttx.apache.org
Cc: Sebastien Lorquet 
Subject: RE: DISCUSSION - Usage of mailing lists for apache projects

Hi all,

I agree with David but in my opinion this information should go in the
commit message and no commit without message should be merged.
Not all people will check the PR message but you will always see the reasons
simply by typing "git log" if they are in the commit message

What do you think ?

Thanks
Alin


-Original Message-----
From: David Sidrane 
Sent: den 9 mars 2023 10:00
To: dev@nuttx.apache.org
Cc: Sebastien Lorquet 
Subject: RE: DISCUSSION - Usage of mailing lists for apache projects

I would add that all pull request must have a statement explaining the
reason or motivation for the change(s).

Just stating the "What" was done is not enough. There must be a "Why" the
change is needed.

David

-Original Message-
From: alin.jerpe...@sony.com 
Sent: Thursday, March 9, 2023 3:39 AM
To: dev@nuttx.apache.org
Cc: Sebastien Lorquet 
Subject: RE: DISCUSSION - Usage of mailing lists for apache projects

Hi all,

I  feel that this thread is getting too long without a real outcome

Some observations from my daily interactions with the project:
- I like doing reviews on github and I think that many people in this thread
would agree that this flow is good.
- I like to be able to see all bugs in one place and get statistics  for the
ASF reports

What I don’t feel right
- even if I spend time daily on reviewing patches there are still changes
that I miss and it is hard to get the flow on release date
- some breaking changes are not discussed enough with the community since
there are some people that do not have time to review code on gihub.

As a way going forward I propose that we improve in 2 aspects
- All breaking commits should be discusses on dev so that people get enough
time to digest the change and even better get involved int the flow
- all breaking changes should be documented on the release confluence page
before merging so that we don’t miss mentioning them on release date.
- there should be at least 1 independent reviewer (not from the same
company) so that a patch is merged except board changes (ex an employee from
the same company merges a patch submitted by another employee from the same
company, for a board provided by the same company)

Thanks
Alin

-Original Message-
From: Alan C. Assis 
Sent: den 8 mars 2023 19:15
To: dev@nuttx.apache.org
Cc: Sebastien Lorquet 
Subject: Re: DISCUSSION - Usage of mailing lists for apache projects

Hi Lwazi,

It is not sarcarm, I'm talking about facts.

Also I didn't say Sebastien points aren't valid, but is diverting from the
real issue.

The issue is not if the discussion is happening here or there, the Problem
is that we don't have enough reviewers.

So, first step is that NuttX needs to increase the user base, but have few
users really engaged with the project, reviewing patches every single day.
Currently today he have few: Petro and Xiang are exceptional on this point.
They are my inspiration to try do more!

Welcome back go NuttX Lwazi (I'm not been sarcastic, I'm happy to hear from
you again! You have a great knowledge of BLE can we need! I was expecting
you to share that working example of BLE application using our BLE stack).

BR,

Alan

On 3/8/23, Lwazi Dube  wrote:
> On Wed, 8 Mar 2023 at 09:55, Alan C. Assis  wrote:
>>
>> Sebastien,
>>
>> If all the discussions that happens on github start to happen here,
>> this mailing list will be just like the nuttx-commits mailing list.
>
> I'll take this as sarcasm. Sebastien is making a lot of valid points,
> in good faith, and being dismissive does not help the community.
>

RE: DISCUSSION - Usage of mailing lists for apache projects

[David Sidrane]

I would add that all pull request must have a statement explaining the
reason or motivation for the change(s).

Just stating the "What" was done is not enough. There must be a "Why" the
change is needed.

David

-Original Message-
From: alin.jerpe...@sony.com 
Sent: Thursday, March 9, 2023 3:39 AM
To: dev@nuttx.apache.org
Cc: Sebastien Lorquet 
Subject: RE: DISCUSSION - Usage of mailing lists for apache projects

Hi all,

I  feel that this thread is getting too long without a real outcome

Some observations from my daily interactions with the project:
- I like doing reviews on github and I think that many people in this thread
would agree that this flow is good.
- I like to be able to see all bugs in one place and get statistics  for the
ASF reports

What I don’t feel right
- even if I spend time daily on reviewing patches there are still changes
that I miss and it is hard to get the flow on release date
- some breaking changes are not discussed enough with the community since
there are some people that do not have time to review code on gihub.

As a way going forward I propose that we improve in 2 aspects
- All breaking commits should be discusses on dev so that people get enough
time to digest the change and even better get involved int the flow
- all breaking changes should be documented on the release confluence page
before merging so that we don’t miss mentioning them on release date.
- there should be at least 1 independent reviewer (not from the same
company) so that a patch is merged except board changes (ex an employee from
the same company merges a patch submitted by another employee from the same
company, for a board provided by the same company)

Thanks
Alin

-Original Message-
From: Alan C. Assis 
Sent: den 8 mars 2023 19:15
To: dev@nuttx.apache.org
Cc: Sebastien Lorquet 
Subject: Re: DISCUSSION - Usage of mailing lists for apache projects

Hi Lwazi,

It is not sarcarm, I'm talking about facts.

Also I didn't say Sebastien points aren't valid, but is diverting from the
real issue.

The issue is not if the discussion is happening here or there, the Problem
is that we don't have enough reviewers.

So, first step is that NuttX needs to increase the user base, but have few
users really engaged with the project, reviewing patches every single day.
Currently today he have few: Petro and Xiang are exceptional on this point.
They are my inspiration to try do more!

Welcome back go NuttX Lwazi (I'm not been sarcastic, I'm happy to hear from
you again! You have a great knowledge of BLE can we need! I was expecting
you to share that working example of BLE application using our BLE stack).

BR,

Alan

On 3/8/23, Lwazi Dube  wrote:
> On Wed, 8 Mar 2023 at 09:55, Alan C. Assis  wrote:
>>
>> Sebastien,
>>
>> If all the discussions that happens on github start to happen here,
>> this mailing list will be just like the nuttx-commits mailing list.
>
> I'll take this as sarcasm. Sebastien is making a lot of valid points,
> in good faith, and being dismissive does not help the community.
>

Is there a current list of functions that can be called from interrupt context.

[David Sidrane]

Hi,



There has been a lot of good work and changes in system for mm, logging,
synchronization, and networking.



Do we have a current list of functions that can be called from interrupts?



Should we consider a documentation pass to mark these?



David

RE: Serial driver: No BREAK support?

[David Sidrane]

Hi Nathan,

As far as I know Breaks are Asynchronous (not buffer)

By definition: a BREAK is a Start bit that lasts for more bit times then the
configured word size, parity and stop bit times. This is how the receiver
detects it.

AFAIN NuttX can not propagate the reception of the break to an App as a
BREAK and may deliver 0s, (as it delivers bad data on parity in some
drivers.)

When sending a Break, the app can use other IOCTL to ensure the data is
sent. Then Issue the break (stop issuing) and then resume.

David

-Original Message-
From: Nathan Hartman 
Sent: Tuesday, January 31, 2023 8:12 AM
To: dev@nuttx.apache.org
Subject: Re: Serial driver: No BREAK support?

Hi David,

If I understand correctly, if there is ongoing transmit of data that was
previously buffered, this will mask it?

In other words, if O_NONBLOCK and the application does something like:

write(...);
ioctl(TIOCSBRK);
write(...);

then the Break will not necessarily be transmitted between the two writes.
It will very likely be transmitted during the first write, masking part of
that write.

Is my understanding correct, and is that the intended behavior?

Thanks for that link. I didn't know about TIOCSBRK.

Nathan

On Tue, Jan 31, 2023 at 2:27 AM David Sidrane 
wrote:

> Hi Nathan,
>
> Have you seen
>
> https://github.com/apache/nuttx/blob/master/arch/arm/src/stm32f7/stm32
> _serial.c#L2657
> ?
>
> David
>
> -Original Message-
> From: Nathan Hartman 
> Sent: Monday, January 30, 2023 7:16 PM
> To: dev@nuttx.apache.org
> Subject: Serial driver: No BREAK support?
>
> Serial communications sometimes use a condition called BREAK [1]. I
> need to interface to 3rd party equipment that uses this feature.
>
> In Unix-like OSes a BREAK can be sent by calling termios function
> tcsendbreak() or ioctl TCSBRK.
>
> NuttX has an extern declaration for tcsendbreak() and a #define for
> TCSBRK.
> However, there is no implementation for these in the serial driver (no
> such function, no handling for this IOCTL).
>
> I am wondering how to implement this in the serial driver. I know that
> the basic change is:
>
> (1) In libs/libc/termios/, add new file lib_tcsendbreak.c which calls
> ioctl TCSBRK.
>
> (2) In drivers/serial/serial.c uart_ioctl(), add a case for TCSBRK
> which calls the upper half driver, e.g., new function uart_tcsendbreak().
>
> (3) In uart_tcsendbreak(), do some magic.
>
> That magic is the question:
>
> What if there is pending transmit data? Then BREAK should happen after
> transmit done but before any new transmit data.
>
> What if filep->f_oflags & O_NONBLOCK? Then how does the driver
> schedule BREAK to happen after transmit done but before new transmit data?
>
> Any ideas would be appreciated.
>
> References:
> [1]
> https://stackoverflow.com/questions/1279478/rs-232-break-signal#127967
> 1
>
> Cheers,
> Nathan
>

RE: Serial driver: No BREAK support?

[David Sidrane]

Hi Nathan,

Have you seen
https://github.com/apache/nuttx/blob/master/arch/arm/src/stm32f7/stm32_serial.c#L2657
?

David

-Original Message-
From: Nathan Hartman 
Sent: Monday, January 30, 2023 7:16 PM
To: dev@nuttx.apache.org
Subject: Serial driver: No BREAK support?

Serial communications sometimes use a condition called BREAK [1]. I need to
interface to 3rd party equipment that uses this feature.

In Unix-like OSes a BREAK can be sent by calling termios function
tcsendbreak() or ioctl TCSBRK.

NuttX has an extern declaration for tcsendbreak() and a #define for TCSBRK.
However, there is no implementation for these in the serial driver (no such
function, no handling for this IOCTL).

I am wondering how to implement this in the serial driver. I know that the
basic change is:

(1) In libs/libc/termios/, add new file lib_tcsendbreak.c which calls ioctl
TCSBRK.

(2) In drivers/serial/serial.c uart_ioctl(), add a case for TCSBRK which
calls the upper half driver, e.g., new function uart_tcsendbreak().

(3) In uart_tcsendbreak(), do some magic.

That magic is the question:

What if there is pending transmit data? Then BREAK should happen after
transmit done but before any new transmit data.

What if filep->f_oflags & O_NONBLOCK? Then how does the driver schedule
BREAK to happen after transmit done but before new transmit data?

Any ideas would be appreciated.

References:
[1] https://stackoverflow.com/questions/1279478/rs-232-break-signal#1279671

Cheers,
Nathan

RE: Intertask communication in NuttX

[David Sidrane]

Have you looked at uOrb?

-Original Message-
From: Roberto Bucher 
Sent: Saturday, December 17, 2022 1:53 AM
To: dev@nuttx.apache.org
Subject: Intertask communication in NuttX

Hi

after successfully reached to recompile the microROS environment, I'd like
to build an intertask communication between a microROS node and a pysimCoder
generated code.

I think that I can't use a shared memory with my embedded system
(nucleo-144), because I can't see the CONFIG_BUILD_KERNEL=y in my .config
file.

Are there other IPC mechanism that I can use to communicate between the
2 tasks?

Thanks in advance

Roberto

RE: SAM-E70 progmem - in system programming and RAMFUNCS

[David Sidrane]

Have you ensured that all the code (and support code, systic etc) is in RAM?

Also, Is this an ECCed FLASH? Is the write size correct? We must line cache
the writes on some parts in the PX4 bootloader.

https://github.com/PX4/PX4-Autopilot/blob/main/platforms/nuttx/src/bootloader/common/lib/flash_cache.c


David
-Original Message-
From: James Dougherty 
Sent: Friday, December 9, 2022 12:46 AM
To: dev@nuttx.apache.org
Subject: Re: SAM-E70 progmem - in system programming and RAMFUNCS

Thank you Greg, Thank you David!

I did check that is correct:

arch/arm/src/samv7/sam_start.c - 344:356

  /* Copy any necessary code sections from FLASH to RAM.  The correct
   * destination in SRAM is geive by _sramfuncs and _eramfuncs.  The
   * temporary location is in flash after the data initialization code
   * at _framfuncs.  This should be done before sam_clockconfig() is
   * called (in case it has some dependency on initialized C variables).
   */

#ifdef CONFIG_ARCH_RAMFUNCS
  for (src = &_framfuncs, dest = &_sramfuncs; dest < &_eramfuncs; )
{
  *dest++ = *src++;
}
#endif

Also looks correct - in: same70-xplained/samv7-scripts/flash-sram.ld -
36:113

/* The SAME70Q21 has 2048Kb of FLASH beginning at address 0x0040: and
 * 384Kb of SRAM beginining at 0x2040:
 *
 * When booting from FLASH, FLASH memory is aliased to address 0x:
 * where the code expects to begin execution by jumping to the entry point
in
 * the 0x0400: address range (Assuming that ITCM is not enable).
 */

MEMORY
{
flash (rx) : ORIGIN = 0x0040, LENGTH = 2048K sram (rwx) : ORIGIN =
0x2040, LENGTH = 384K }

OUTPUT_ARCH(arm)
EXTERN(_vectors)
ENTRY(_stext)

SECTIONS
{
.text : {
_stext = ABSOLUTE(.);
*(.vectors)
*(.text .text.*)
*(.fixup)
*(.gnu.warning)
*(.rodata .rodata.*)
*(.gnu.linkonce.t.*)
*(.glue_7)
*(.glue_7t)
*(.got)
*(.gcc_except_table)
*(.gnu.linkonce.r.*)
_etext = ABSOLUTE(.);
} > flash

.init_section : {
_sinit = ABSOLUTE(.);
*(.init_array .init_array.*)
_einit = ABSOLUTE(.);
} > flash

.ARM.extab : {
*(.ARM.extab*)
} > flash

__exidx_start = ABSOLUTE(.);
.ARM.exidx : {
*(.ARM.exidx*)
} > flash
__exidx_end = ABSOLUTE(.);

_eronly = ABSOLUTE(.);

.data : {
_sdata = ABSOLUTE(.);
*(.data .data.*)
*(.gnu.linkonce.d.*)
CONSTRUCTORS
_edata = ABSOLUTE(.);
} > sram AT > flash

.ramfunc ALIGN(4): {
_sramfuncs = ABSOLUTE(.);
*(.ramfunc  .ramfunc.*)
_eramfuncs = ABSOLUTE(.);
} > sram AT > flash

_framfuncs = LOADADDR(.ramfunc);

.bss : {
_sbss = ABSOLUTE(.);
*(.bss .bss.*)
*(.gnu.linkonce.b.*)
*(COMMON)
_ebss = ABSOLUTE(.);
} > sram

To David's point, I looked at NVIC since I have CONFIG_ARCH_RAMVECTORS.
arm/src/samv7/samv7_irq.c

#ifdef CONFIG_ARCH_RAMVECTORS
  /* If CONFIG_ARCH_RAMVECTORS is defined, then we are using a RAM-based
   * vector table that requires special initialization.
   */

  up_ramvec_initialize();
#endif

arm/src/armv7-m/up_ramvec_initialize.c
after we copy the ram vectors:

/* Now configure the NVIC to use the new vector table. */
putreg32((uint32_t)g_ram_vectors, NVIC_VECTAB);

and after sam_bringup.c

 printf("NVIC: 0x%08x\n",   getreg32(NVIC_VECTAB));

NVIC: 0x20401180

Looks good.

And yes, still hitting flash on exception:

flash_erasell /dev/mtd0

Whammo - hardfault in openocd monitor:

target halted due to debug-request, current mode: Handler HardFault
xPSR: 0x8103 pc: 0x00401114 msp: 0x204025e8

Try to flash the lower 256KB of flash, works like a champ:

nsh> sdflash 0x44 /mnt/sdcard/nuttx.bin /
..
..
..
Installed application of size 233692 bytes to program memory [44h -
4790dch].
nsh> reboot

So tomorrow, I will maybe move the image to another location in flash and
hack up the linker script.
Also do a detailed read on the errata, Petro mentioned there is some
possible chip bug, maybe that is it ..
There is some nasty Komodo dragon lurking in there, hissing and snapping at
ankles ... SAMV7 doesn't work like an STM32F1/F4/F7 which all work perfectly
on this codebase.. could also be a timing issue - 300Mhz core clock and
150Mhz AHB clock, I will try to slow it down and change the flash wait
states also ... maybe a bus error is occuring.

I will pick this up again tomorrow, any ideas, please share!

Thank you for your time and attention to this issue...
-James







On Thu, Dec 8, 2022 at 7:57 AM Gregory Nutt  wrote:

> On 12/8/2022 5:55 AM, David Sidrane wrote:
> > Is the NVIC_VTABLE repointed to the RAM vectors?
>
> The RAM functions are like .bss:  There is a storage area of code that
> that is copied into RAM only power up.  But the symbols associated
> with the RAMFUNCs are defined by the linker script to be the address
> of the

RE: New names of repositories

[David Sidrane]

> I vote for nuttx, nuttx-apps

+1

David

-Original Message-
From: James Dougherty 
Sent: Friday, November 18, 2022 11:21 AM
To: dev@nuttx.apache.org
Subject: Re: New names of repositories


That’s right! and underscores are difficult to see when the file name is
displayed as an underlined link

you also can’t use underscores
with AWS S3 …
https://docs.aws.amazon.com/AmazonS3/latest/userguide/bucketnamingrules.html

Finally, the Google search engine treats, the hyphen( ‘-‘ ) separator as a
word separator but the same does not apply to underscores (‘_’)

yes, underscore is great for C code because it is the “space which is not a
space” - however, for file names, because of the reasons above it’s
problematic…

I vote for nuttx, nuttx-apps



> On Nov 18, 2022, at 7:07 AM, TimH  wrote:
>
> I see all the other two-word Apache repositories use hyphens not
> underscores, and on GitHub they are URLs which as has been pointed out
> should ideally be hyphenated?
>
> To me the underscore looks wrong...but, in the grand scheme of things,
> it's just a name and, like Sebastien, I will not lose sleep. I lose enough
> of that already, getting trying to get NuttX working on the processor I'm
> using LOL.
>
>
>
>> -Original Message-
>> From: Sebastien Lorquet 
>>
>> Hi,
>>
>> I would also very much prefer nuttx and nuttx_apps but the other
>> option will not prevent me from sleeping well at night.
>>
>> Sebastien
>>
>>> Le 18/11/2022 à 15:46, Gregory Nutt a écrit :
>>>
 But NuttX has more features than traditional RTOS(e.g. FreeRTOS).
 Actually,
 Xiaomi uses it in the IoT space which has less real time requirements.
 Other similar OS(e.g. Zephyr) doesn't append rtos suffix.
 So, I prefer keep nuttx and nuttx-apps.
>>>
>>> I just endorsed nuttx_rtos and nuttx_apps, but Xiao is correct.
>>> nuttx_rtos is redundant since nuttx is the name of the RTOS.
>>> nuttx_apps are miscellaneous applications tailored for the NuttX RTOS.
>>> It really is semantically cleaner.
>>>
>

RE: PWM fast stop operation

[David Sidrane]

Hi Petro,

On the STM32 there are shadow registers that buffer the updated data to
ensure that outputs are updated synchronously with the end of the period.
There is a bit that can be set to force the update to the shadowed registers
to be immediate, which will change the count of the current period in that
period. This can be dangerous; in that it could extend a pulse and create an
undesired position or speed. In the case of going to 0, this could create a
runt pulse and also create an undesired position or a slow speed (not so
bad), Because the update is asynchronous the pulse with the output, it is
not deterministic. So synchronous updates are a good thing most times.

David


-Original Message-
From: Petro Karashchenko 
Sent: Friday, November 11, 2022 6:50 PM
To: dev@nuttx.apache.org
Subject: PWM fast stop operation

Hello team,

Recently I had a project where I had to control a motor using PWM. In
general things worked pretty well, but I've met an issue when I need to stop
PWM as soon as possible. My custom board is based on SAMv7 and uses the
standard NuttX PWM driver. The issue with the SAMv7 PWM peripheral is that
when a PWM stop is issued the PWM generation is not stopped immediately, but
waits at the end of the current cycle. I'm not sure if that is unique to
SAMv7, so maybe you can give feedback about the other platforms. Initially I
tried to replace stop by keeping PWM running and updating config to have 0%
duty cycle, but that still waits till the end of the current cycle to apply.
The SAMv7 PWM has a signal override capabilities, so I used that instead of
stopping the PWM. I've extended the "struct pwm_info_s" structure and
included an override field there, but feel that it might not be the best
approach.

I would appreciate your advices on what is the best way to integrate output
override feature into existing PWM driver.

Best regards,
Petro

Re: [VOTE] Apache NuttX Community Graduation

[David Sidrane]

+1: Apache NuttX is ready to graduate to TLP

David

On 2022/10/21 12:46:47 Nathan Hartman wrote:
> Dear Apache NuttX Community,
> 
> Following the [DISCUSS] thread which has gone 72 hours without any
> further issues raised [1]:
> 
> This is a call to VOTE on Graduation of Apache NuttX from the
> Incubator to Top-Level Project (TLP).
> 
> Please vote:
> 
> [ ] +1: Apache NuttX is ready to graduate to TLP
> [ ]  0: No opinion
> [ ] -1: Apache NuttX is NOT ready to graduate; please state reason(s)
> 
> If this community vote passes, we will proceed to the next steps. The
> graduation process is documented at [2]. The vote will remain open for
> at least 72 hours. A minimum of 3 binding +1 votes and more binding +1
> than binding -1 are required to pass. The ASF requirements for voting
> can be found at [3].
> 
> Project Highlights Since Incubation:
> * Incubating since 2019-12-09
> * Website migrated to nuttx.apache.org
> * Shipped 9 releases under the ASF Incubator
> * Merged 8000 PRs across incubator-nuttx and incubator-nuttx-apps
> * More than 1000 stars on GitHub
> * More than 500 forks on GitHub
> * More than 250 subscribers to dev@nuttx.apache.org
> * In Top 10 Apache projects of 2021 by number of commits [4]
> * 5 mentors
> * 18 PPMC members
> * 26 committers
> * 75 ICLAs
> * 2 CCLAs
> * 21 SGAs
> * 2 release managers
> * 3 NuttX online workshops
> * And much, much more
> 
> Let me express a big ***THANK YOU*** to everyone for helping make this
> possible!
> 
> [1] https://lists.apache.org/thread/vpj21ofyxmjs528n3b9s72wozh9hjz8f
> 
> [2] 
> https://incubator.apache.org/guides/graduation.html#graduating_to_a_top_level_project
> 
> [3] https://www.apache.org/foundation/voting.html
> 
> [4] 
> https://thestack.technology/top-apache-projects-in-2021-from-superset-to-nuttx/
> 
> Cheers,
> Nathan Hartman
> 

RE: [DISCUSS] Graduate NuttX as TLP

[David Sidrane]

+1 - The time has come.

David

-Original Message-
From: Xiang Xiao 
Sent: Wednesday, October 19, 2022 1:52 AM
To: dev@nuttx.apache.org
Subject: Re: [DISCUSS] Graduate NuttX as TLP

+1.
We are ready after two years of incubation!

On Wed, Oct 19, 2022 at 1:07 PM Alin Jerpelea  wrote:

> +1
> I think that we are ready to graduate
>
>
> Best regards
> Alin
>
> On Wed, 19 Oct 2022, 06:16 Tomek CEDRO,  wrote:
>
> > Just my vote for the path names:
> > apache/nuttx_rtos
> > apache/nuttx_apps
> >
> > Looks safe and self-explanatory :-)
> >
> > If clone to nuttx_rtos.git/ and nuttx_apps.git/ would be also
> > acceptable that would be perfect (and marked there is a git repo
> > inside).
> >
> > Thank You and Good Luck! :-)
> >
> > --
> > CeDeROM, SQ7MHZ, http://www.tomek.cedro.info
> >
>

Re: STM32H7 SPI status ?

[David Sidrane]

Hi Sebastien,

I think it is a stale artifact from before the DMA was fleshed out.

We are using DMA on the H7  SPI in PX4. The only caveat is that the default
drive strength may be too high and we reduced it with the macro:
https://github.com/PX4/PX4-Autopilot/blob/main/boards/px4/fmu-v6x/nuttx-config/include/board.h#L417-L437


We had a sensor that worked when polled but when DMA was enabled. I could
see massive overshoot on the clock.


*Regards,*


*David*







On Wed, Aug 31, 2022 at 6:26 AM Sebastien Lorquet 
wrote:

> Hi all,
>
>
> SPI bus driver in STM32H7 requires the CONFIG_EXPERIMENTAL feature.
>
> Is that still true as of today?
>
>
> I will do some tests later but I would like to know if someone has
> information about these peripherals, are these working or not, with
> interrupt, dma etc?
>
> Thanks for any info
>
>
> Sebastien
>
>

Re: STM32F103RET6 and HSI

[David Sidrane]

HSI is not a good choice if there are external interfaces. It can vary too
much part to part and over temperature to meet the 2% across the system
boundary. They claim 1% @25c but that is 1/2 the budget to begin with,

https://www.st.com/resource/en/application_note/dm00425536-how-to-optimize-stm32-mcus-internal-rc-oscillator-accuracy-stmicroelectronics.pdf




On Tue, Aug 23, 2022 at 2:10 AM James Dougherty  wrote:

> Anyone ever use the HSI on STM32F103, how about RET6? I know the code is
> set up for HSE. I got it working, at least UART1.
> But now, the other usart devices ... Wondering if anyone has ever run into
> UART baud rate mismatches on using HSI? I have a few
> radios that work great with an existing driver and a diff design, but not
> joy on the F103RET6. I am using internal PLL, x8 (64Mhz)
> and 32Mhz (APB1, APB2) if anyone has any debug pointers that would be
> great. Its weird, the UART1 uses APB2, and others
> use APB1. I know I need the external crystal but I got these boards and no
> clock stuffed... (sigh)
>
> thanks!
> -james
>

RE: IMXRT1020-EVK hardfault on boot

[David Sidrane]

Hi Nicolas,



I have not tested a RT1020 lately. My board is pack becaue I am moving in a
fey days. It will be a several weeks before I can l look at it. Possibly
Dave Marples github @mubes can lend a hand.



David



-Original Message-
From: nicolas.silv...@ludo.tech 
Sent: Monday, August 15, 2022 12:45 PM
To: dev@nuttx.apache.org
Subject: IMXRT1020-EVK hardfault on boot



Hello,





I've been wanting to try out NuttX using the MIMXRT1020-EVK. However, I get
a hardfault at boot which I haven't been able to solve by myself and would
appreciate some help to figure out if i'm doing something wrong or if there
is an issue with the configuration for this board.





I have been able to get the following information :



- Debugger is pointing at mm_initialize.c line 141 after hardfault (I've
included a picture with registers values if that's useful)



- When i enable Memory manager and Scheduler debug, I get the following logs

:



nx_start: Entry



mm_initialize: Heap: name=Umem, start=0x20201da1 size=4294959711



mm_addregion: [Umem] Region 1: base=0x20201f00 size=4294959360







I assume that size is the issue but i haven't been able to fix it myself.



If that matters : I have been using MCUXpresso IDE to flash the board and
I'm using the board is SCH-29856 REV A3







Thanks !



Nicolas

RE: STM32U585: Can't enable peripheral clock for IO port I (GPIOIEN in RCC_AHB2ENR1)

[David Sidrane]

Does the CPU busfault if write the GPIOI MODER? Do the values stick when
written?

-Original Message-
From: Michael Jung 
Sent: Friday, March 25, 2022 9:36 AM
To: dev 
Subject: Re: STM32U585: Can't enable peripheral clock for IO port I (GPIOIEN
in RCC_AHB2ENR1)

Hi David,

Thanks for your reply.   Actually, I am trying to get the B-U585I-IOT02A's
NOR flash chip running, which is connected via OCTOSPI.  I can issue a
single command (READID) to the NOR flash and I get a sane reply, but any
follow-on command will just return nonsense (more specifically, the READID
reply will be returned over and over again).  This seemed to point to
problems with the nCS signal, which turned out to be on PI5. I then realized
via JTAG/SVD that GPIOIEN is not set. Single stepping through the code I see
that the value 0x802001ff is written to RCC_AHB2ENR1, but reading back the
register returns 0x802000ff.

The stm32l5, which I based the stm32u5 code on, did not have an IO port I.
I must have missed a piece of logic during porting I guess.

Bye,
Michael

Am Fr., 25. März 2022 um 17:22 Uhr schrieb David Sidrane <
david.sidr...@nscdg.com>:

> Hi Michael,
>
> Odd. Did you check the defines? How are you verifying it? Have you
> JTAG-ed it, could it be bad SVD? Have you just printed the value to be
> set and the result ?
>
> David
>
> -Original Message-
> From: Michael Jung 
> Sent: Friday, March 25, 2022 9:07 AM
> To: dev 
> Subject: STM32U585: Can't enable peripheral clock for IO port I
> (GPIOIEN in
> RCC_AHB2ENR1)
>
> Hello,
>
> This is more about STM32 than it is about NuttX, but I know there are
> experts here:  STM32U585 does have 8 GPIOs on Port I.  However,
> setting bit
> 8 (GPIOIEN) in RCC_AHB2ENR1 seems to be ignored (i.e. GPIOIEN remains
> at 0).
> For the other eight IO ports (GPIO[A-H]EN) it works just fine.  Any
> ideas anyone?
>
> Thanks!
> Michael
>

RE: STM32U585: Can't enable peripheral clock for IO port I (GPIOIEN in RCC_AHB2ENR1)

[David Sidrane]

Hi Michael,

Odd. Did you check the defines? How are you verifying it? Have you JTAG-ed
it, could it be bad SVD? Have you just printed the value to be set and the
result ?

David

-Original Message-
From: Michael Jung 
Sent: Friday, March 25, 2022 9:07 AM
To: dev 
Subject: STM32U585: Can't enable peripheral clock for IO port I (GPIOIEN in
RCC_AHB2ENR1)

Hello,

This is more about STM32 than it is about NuttX, but I know there are
experts here:  STM32U585 does have 8 GPIOs on Port I.  However, setting bit
8 (GPIOIEN) in RCC_AHB2ENR1 seems to be ignored (i.e. GPIOIEN remains at 0).
For the other eight IO ports (GPIO[A-H]EN) it works just fine.  Any ideas
anyone?

Thanks!
Michael

RE: Serial RX DMA polling

[David Sidrane]

Hi Michal,

> rather from board level section

Yes

Have a look at this example.

https://github.com/PX4/PX4-Autopilot/blob/master/boards/px4/fmu-v5x/src/init.cpp#L243-L247

-Original Message-
From: Michal Lenc 
Sent: Sunday, March 6, 2022 2:38 PM
To: dev@nuttx.apache.org
Subject: Serial RX DMA polling

Hi all,



serial drivers use periodic polling for DMA receive callback to ensure the
reception of bytes that were not taken by DMA interrupt. There are functions
like stm32_serial_dma_poll(void) that should be periodically called from a
timer for this purpose. However I haven´t been able to find any "example"
usage in the NuttX mainline.




My first thoughts were to implement the timer directly to the driver (like
in ADC drivers) but stm32_serial_dma_poll(void) is not private so I guess it
is not supposed to be called from stm32_serial.c but rather from board level
section? Is there any consensus on how to use the periodic polling? Thanks.


Best regards,
Michal Lenc

RE: [DISCUSS]: Self merge and Single company/organization merge gating

[David Sidrane]

On Self merge:

As Nathan pointed out, it is more about time zones then merge velocity.
However, using a backport only methodology requires an upstream merge before
the work can be backported with least effort and adds a serial delay. It
would be ideal to reduces the CI quantum delay this as much as we can.

GH has a setting to merge on successful CI after approval. It is lit by the
approver. This removes the polling for completion of CI.
If this can be configured it reduces the polling for both approver and
author. If it can not be configured in our repos, then self merge is the
next best thing.

I am not trying to circumvent the review process at all - just remove the
idle time imposed by the process that is sampling related.

> an approval from outside of the company/organization then the author can
> do the merge. For complex changes the person outside the organization
> should perform the merge even if there are more than 1 approval from
> inside the company/organization.

I agree.

David

-Original Message-
From: Petro Karashchenko 
Sent: Thursday, February 17, 2022 1:01 PM
To: dev@nuttx.apache.org
Subject: Re: [DISCUSS]: Self merge and Single company/organization merge
gating

Hello,

Regarding PRs megre by the author: I think that if the changes are
relatively simple (again that is very subjective, but I hope that people
with merge rights have more or less the same common sense of
it) and there is an approval from outside of the company/organization then
the author can do the merge. For complex changes the person outside the
organization should perform the merge even if there are more than 1 approval
from inside the company/organization.

In this way reviewers can perform reviews with better quality and if someone
"forget" to press the "rebase & merge" button because for example CI is
still running and that is the end of working day, then the author can press
that button and not do extra tagging in PRs. I vote to make that process
usable for people and sacrifice bureaucracy in the places where it is
possible.

Best regards,
Petro

вт, 15 лют. 2022 р. о 18:26 Nathan Hartman  пише:
>
> On Mon, Feb 14, 2022 at 2:01 PM Brennan Ashton
>  wrote:
> > > Background:
> > I am generally opposed to both of these. It is quite rare that we
> > need a crazy fast merge turn around on a PR. And if something is
> > approved and straight up broken in master that needs to get in then
> > I think forgiveness can be used to self merge.
> >
> >
> > I also generally do not have a big issue about people from the same
> > company reviewing and merging. I could see the arguments for shared code
> > but then I
> > think we are nitpicking.   I prefer the velocity with a few oops that
> > can
> > be reverted along the way if needed.  There is also parts of the
> > code base where the best people to review are on the same company.
> >
> >
> > I think most of the concerns here are best addressed not by process
> > but increasing the number of contributors who can participate. (more
> > committers and PPMC)
>
> Feel free to correct me if I'm mistaken, but I think David is bringing
> this up because of time zones.
>
> Indeed, most of the PR merging activity seems to occur during what I
> would call nighttime or early morning, and I think that might be more
> pronounced in David's time zone.
>
> Still, I think things have been working well, more or less, and I
> don't think we need to make up any new rules right now.
>
> Instead, I would only urge committers to give complex PRs 12-24 hours
> to percolate, even if there's an approving review, so other time zones
> have a chance to look at them.
>
> Obviously that doesn't apply if it's urgent. For example, if the build
> is broken and people can't get work done, or a serious error was
> merged and needs to be reverted ASAP, don't wait, do it!
>
> Also, it's not necessary to delay for trivial PRs.
>
> What are the definitions of "complex," "trivial," "urgent," etc? I
> say, committers should just use their best judgment and try to find a
> good balance. Don't rush too much, don't delay too much. :-)
>
> David brings up a good point about time zones and we do have to
> remember that NuttX is a global project, and I think that's the main
> point to keep in mind.
>
> To Brennan's last point: as we grow the committer base, we are likely
> to have more people in more time zones and more PR reviewers, so this
> should become less of a concern.
>
> Nathan

[DISCUSS] Default state of NDEBUG

[David Sidrane]

PR 5399 adds an Kconfig option for NDEBUG. The salient discussion begins at
[2] there are mixed positions and reasoning. xiaoxiang781216 asked me to
raise a discussion on this.



The reasoning for the Default state of to be NDEBUG (n) hence undefined so
that assert() enabled is the following:



1)  It follows the standard understanding of NDEBUG



  The standard for standard library from [3]



 The definition of the macro assert depends on another macro,
NDEBUG, *which is not defined* by the standard library.





  2) We have DEBUGASSERT for use in the OS. I believe this was an
intentional separation on Greg’s part. We have asked for is input.



In a NuttX "Release" build DEGUASSERT is off (all debug is off to show off
the build size).

I should still be able to build the app code with assert() and not have to
use a Kconfig to enable it.

How would you prefer it to be defined?



   1. Defaulted ON – assert() is a No OP
   2. Defaulted OFF assert() is enabled.
   3. Left to a command line setting from build system



David



[1] https://github.com/apache/incubator-nuttx/pull/5399



[2]
https://github.com/apache/incubator-nuttx/pull/5399#issuecomment-1029387606

[3]
https://en.cppreference.com/w/c/error/assert#:~:text=If%20NDEBUG%20is%20defined%20as,the%20source%20code%20where%20%3Cassert.=If%20NDEBUG%20is%20not%20defined,output%20and%20calls%20abort()
.

[DISCUSS]: Self merge and Single company/organization merge gating

[David Sidrane]

I am opening this discussion to widen the audience for feedback on the
rules for merging. The original interexchange was in [1]



1 ) Given the geographical and time differences should we consider that
once a review with approval* has been done the PR’s author can merge it?



2) Should we consider requiring more than one organization/company to
approve a PR before it is merged.



Background:



If only one company does a review, that can lead to undo influence as noted
as the "The Enemies"
 of
the INVIOLABLES [2]:

“Focus on the values of the organization, not the values of the Open Source
project. Need to support both.”

*The change would define PR approval as requiring a review/approval from
more than the members of one company or organization.





I am in favor of both these changes.



David



[1]
https://github.com/apache/incubator-nuttx/pull/5320#issuecomment-1020379240

[2] https://github.com/apache/incubator-nuttx/blob/master/INVIOLABLES.md

RE: arm/kinetis vs arm/kl

[David Sidrane]

Hi Karel,

It depends on the level of intrusion. You are closer to the problem then I
am. So, I will share what I know and hopefully a clear path will emerge for
you. I do not know the history of the KL.

The Kinetis arch has a notion of IP versioning. See
https://github.com/apache/incubator-nuttx/blob/master/arch/arm/include/kinetis/kinetis_mcg.h#L35-L48
and
https://github.com/apache/incubator-nuttx/blob/master/arch/arm/include/kinetis/kinetis_sim.h#L34-L51
for some references. If the code can be added using or extending notion of
IP versioning that is the way to go. It reduces ifdef rash to features not
chips.

If the KL8xZ is closer to the KL than the Kinetis. it would be fine to copy
over the IP drivers from the Kinetis to the KL. This is preferred to reduce
coupling and ifdef rash. The maintenance effort is higher, but the
decoupling avoids a break-it fix-it loop we have seen on STM32.

Regard,

David


-Original Message-
From: Karel Kočí 
Sent: Monday, January 31, 2022 6:35 AM
To: dev@nuttx.apache.org
Subject: arm/kinetis vs arm/kl

Hi everyone

I am trying to port NuttX to NXP KL8xZ chips. I already did memory map, irq,
pinmux, rom config and other tweaks but now when I want to get UART up and
running I kind of started thinking if I am doing the right thing. Let me
explain...

I forked kl25z support in hopes that it is closest to the kl81z. It is from
same series, it is also based on Cortex-M0+ (armv6). But it is not exactly
smooth saling (although I did not expect it would be). The system
integration module has a bit different layout but most notably there are
different peripherals. For example lpuart is not implemented in lp but the
implementation in kinetis is pretty much spot on.

My original understanding was that arm/kinetis is intended for armv7 and
arm/kl for amv6. Thus, my question is: is that true? Or is it just some
historical division?

I can now either move the whole fork to the kinetis directory (and work out
armv6 vs 7 switch) and use already implemented drivers there, or I can copy
drivers to kl directory. What do you think is the best course of action?

Any hint or suggestion is appreciated.
With regards
Karel Koci

RE: kconfig-frontends-win32-3.12.1 for windows failed to support some Kconfig syntax?

[David Sidrane]

Yes. This has been discussed here:
https://github.com/apache/incubator-nuttx/issues/2405

-Original Message-
From: xyluo 
Sent: Friday, January 21, 2022 9:05 PM
To: dev 
Subject: kconfig-frontends-win32-3.12.1 for windows failed to support some
Kconfig syntax?

Hello,
Recently I need to build nuttx on windows platform. and the build steps
are done according to the nuttx/README.txt.
The kconfig-frontends-win32-3.12.1 was downloaded from https
://github.com/reclone/kconfig-frontends-win32.MinGW 6.3.0 was also
installed on windows 7.
But it seems the kconfig-frontends-win32-3.12.1 do not support the
expression like 'IMXRT_DTCM > 0'.
Take the arch/arm/src/imxrt/Kconfig for example. When parsing the Kconfig,
the kconfig report errors as
follows.#
.\tools\kconfig.bat menuconfigarch/arm/src/imxrt/Kconfig:1504: syntax
errorarch/arm/src/imxrt/Kconfig:1503: invalid
optionsome
parts of of the imxrt/Kconfig source are like this, and the line 1503 is
the expression:  depends on IMXRT_DTCM >
0.config
IMXRT_DTCM_HEAP bool "Add DTCM to heap" depends on IMXRT_DTCM > 0
---help---  Select to add the entire DTCM to the
heapthe
command '.\tools\kconfig.bat menuconfig' runs ok if I change the code like
this.
config
IMXRT_DTCM_HEAP bool "Add DTCM to heap" depends on IMXRT_DTCM   ---help---
Select to add the entire DTCM to the
heap
It seems the kconfig-frontends-win32-3.12.1 do not support the expression
like 'IMXRT_DTCM > 0'.
Is that right? who can help explain this? Thanks a lot.

Re: STM32U5 support

[David Sidrane]

Hi Michael,

Of course you are much closer to the problem than I am. So here is just my
opinion based on the stm32, stm32f7,  stm32h7 lessons.

Are the L5 and U5 the same with different marketing names or are there
underlying IP differences? What is the delta?

I would head the direction of splitting them up unless there are only minor
pin map differences and then do those as wrapped includes (see the
stm32F412).

The decoupling adds maintenance overhead but prevents the breakage that we
endured in the stm32.



 David


On Wed, Dec 8, 2021 at 10:54 PM Michael Jung  wrote:

> Hello everybody,
>
> I have started to work on STM32U5 support for Apache NuttX and would like
> to get some feedback on how this should be integrated.  Realizing that
> support STM32F0, STM32L0 and STM32G0 is all handled within
> /arch/arm/src/stm32l0g0f0, I would like to rename /arch/arch/src/stm32l5 to
> /arch/arm/src/stm32l5u5 and change filenames and literals accordingly.
> Would you please let me know whether corresponding changes will be
> acceptable?
>
> Thanks!
> Michael
>

RE: Kernel ticking and progmem writes

[David Sidrane]

Is this a dual bank part? Is so you can avoid the bus lock by operating on
the other bank.

-Original Message-
From: Nathan Hartman 
Sent: Tuesday, November 30, 2021 5:35 AM
To: dev@nuttx.apache.org
Subject: Re: Kernel ticking and progmem writes

On Tue, Nov 30, 2021 at 8:05 AM Fotis Panagiotopoulos 
wrote:

> I found the issue.
>
> From the STM32F427 manual:
>
> > Any attempt to read the Flash memory on STM32F4xx while it is being
> written or erased,
> > causes the bus to stall. Read operations are processed correctly
> > once the
> program
> > operation has completed. This means that code or data fetches cannot
> > be
> performed while
> > a write/erase operation is ongoing.
>
> So, although there isn't any critical section anywhere, the CPU halts
> as it cannot access the Flash memory.


I think it may be necessary to put some parts of the NuttX kernel into RAM
so that it can keep executing while the bus is stuck.

I don't know off the top of my head whether we currently have a built-in way
to do that.

Nathan

RE: Custom audio capabilities

[David Sidrane]

Hi Tim,

Emails are getting to the list.

David

-Original Message-
From: Tim 
Sent: Monday, November 22, 2021 3:26 AM
To: dev@nuttx.apache.org
Subject: RE: Custom audio capabilities

I appreciate no one may have any comments or suggestions but since I have
had no replies to my last 2 or 3 questions, could someone kindly just reply
with a "hello" or something, simply to confirm my emails are getting through
OK?

>-Original Message-
>From: TimH 
>Sent: 21 November 2021 16:45
>To: dev@nuttx.apache.org
>Subject: Re: Custom audio capabilities
>
>On 20/11/2021 13:40, TimH wrote:
>> Hi,
>>
>> I'm adding arch support for the sama5d2 Class D audio peripheral.
>>
>> This has bass cut/boost and treble cut/boost capabilities which don't
>> fit (as best as I can tell) with the current set of audio driver
>> capabilities and are, quite probably, unique to this device and not
>> applicable to others (right now at least).
>>
>> I don't think this a case where custom board_ioctl commands are
>> relevant as it is chip specific not board specific.
>>
>> This could be a case of I'm the only one who ever wants to expose
>> this so I could go down that route but assuming it's not technically
>> the right approach, what is, please?
>>
>> Thanks,
>>
>> Tim.
>>
>Since "Feature Unit" controls has run out of bit positions for anything
>new, how about I add the new sama5d2 boost/cut modes into the
>Processing Unit category? Not a great fit but perhaps acceptable?

RE: STM32F7/H7: DAC driver missing?

[David Sidrane]

Hi

If it is not all there then most likely you will have to port it.

David

-Original Message-
From: Frank-Christian Kruegel [mailto:nu...@istda.com]
Sent: Thursday, July 22, 2021 2:00 AM
To: dev@nuttx.apache.org
Subject: STM32F7/H7: DAC driver missing?

Hi.

I'm wondering where the driver for the STM32F7/H7 DACOUT pins is. For
STM32F7 I can select DACOUT1 and DACOUT2 in menuconfig, but I don't find
any accompanying source code. For STM32H7 I find traces of DAC
configuration, but work there seems to be still in progress.

For STM32F4 I do find a dac.c and dac.h.

I my assumption right that I need to port the F4 driver myself in order
to get an F7/H7 driver?

Best regards
Frank-Christian

RE: [Discuss] Migrate the build system to CMake

[David Sidrane]

First, I would like to apologies to Matias for not being able to contribute
to the effort. We are working on the PX4 release, and a nuttx upgrade and I
just do not have the time to spare.



Ironically time is one of the things this discussion is all about. PR with
the current build system and CI take hours to complete.





Yes hours!



This may a not be an issue for the causal Nuttx contributor.  For
maintainers it is a waste of time and money from their companies or
sponsors. It slows development progress down to a crawl.



This is one of the key reasons why we need Cmake, Nijabuild, and ccache
(and persistence).



I am reminded by the 'if it ain't broke..." statement of the proud
carpenter holding his hand saw, in hand, watching the guy cutting plywood
sheeting with a Skill Saw. Saying if it ain't broke



That is the level of improvement that we are talking about. Yes but now you
need power on the job site…. Yes we have to overcome the barriers…



There are a lot of changes happening in NuttX. The immediate value versus
the level of effort to upgrade is difficult to see sometimes. For instance,
in building PX4 with master I have a PR with 666 some odd files changes
tracking the inttypes change and header file inclusion changes. While
typing PRI... thousands of times it is hard to remember that catching the
cause of a crash in the compiler, at build time is far superior to hours
spent in the debugger. The include file changes add proper partitioning
this is a code quality issue.



Sometimes it seems like syntactical sugar or gratuitous renaming changes
are just dumb. They are not. What is dumb is not sharing the sed script or
a text file with the key was/is changes as part of the release. That is on
us. Hats off to AlexanderVasiljev for his comments in [1]. We need to do
this more! No Really we do. Sharing the reasons for the change and how to
apply it to a derivative of NuttX will make NuttX more successful.



Cmake is not in that class of gratuitous changes. The advantage of 22
second out of tree NuttX build will be an obvious. Yes it is a new tool,
yes there is a learning curve, yes I hate cmake some times.



The level of effort for adoption is very high for NuttX. Getting to a
successful build is the first roadblock. Expecting contributors to find and
use buried tooling as opposed to top level commands just digs the hole
deeper.



Is anyone getting tiered of telling contributors "just run
./tools/checkpatch.sh -g HEAD~...HEAD" yet?



If the readme said:



Installing the Tools



Run tools/nuttxtools_install.sh



Building the code



  make board-config

  make board-config menuconfig|newconfig|saveconfig



Check formatting



  make format



Getting to a successful build would be simple.



Cmake will help with this goal on all OS platforms. We just need to invest
in supporting Cmake. Rebasing it constantly is not an option it will
eventually need to be on master. We can keep make and cmake side by side if
we can find value in it.



One other thing I would like to say is PX4 went from make to Cmake years
ago now. It promoted adoption. I would never go back. Even hating cmake,
sometimes the benefits far out way the hassles.



>From that experience I can say it is important to do it right (refractor
with good design reviews of the user experience) and document it well. But
all the user has to type is `make board-config`



Regards,



David





[1] https://github.com/apache/incubator-nuttx/pull/3836#issue-660639554



-Original Message-
From: Matias N. [mailto:mat...@imap.cc]
Sent: Wednesday, June 09, 2021 5:01 PM
To: dev@nuttx.apache.org
Subject: Re: [Discuss] Migrate the build system to CMake



Hi,

I'll answer a few question that came up several times about build systems

co-existing. My previous answer was about co-existing them as a way to
satisfy

both set of users, which I don't think is the right approach. However, as a
transition

approach it does makes sense to me.



This is technically feasible however it will require adapting the Make
based system

as there were some changes needed to be made to Kconfig files, specifically
this one:



https://github.com/apache/incubator-nuttx/pull/3704/files?file-filters%5B%5D=.dat%5B%5D=.pl%5B%5D=.sh%5B%5D=No+extension#diff-7c9693e9c5e61a1d80e09769377d47bb415ec39ca5aeaa85d13581b0105d6359



The main point is that CMake handles all steps related to build
configuration (e.g. build flags based on

optimization level) and platform detection. On master this is done via
Kconfig (with

settings which are stored in board defconfigs). One of these changes done
to Kconfig

is to pass the host-related variables as environment vars to Kconfig (so
that it still

possible to condition options based on platform).

So, co-existing the build systems would require dealing with this, which
I'm not sure

how easy would be.



With regards to comments about others requiring some hands-on time to become

familiar with the system and 

RE: Memory locations

[David Sidrane]

Here is a working example.


https://github.com/apache/incubator-nuttx/blob/master/arch/arm/src/stm32h7/stm32_spi.c#L715-L716

https://github.com/apache/incubator-nuttx/blob/master/boards/arm/stm32h7/nucleo-h743zi/scripts/flash.ld#L179-L184

You can check it the arm-none-eabi-nm -C nuttx.elf | grep g_mcan0_msgram

David

-Original Message-
From: Tim Hardisty [mailto:t...@jti.uk.com.INVALID]
Sent: Tuesday, June 08, 2021 4:23 AM
To: dev@nuttx.apache.org
Subject: Re: Memory locations


On 07/06/2021 19:06, Nathan Hartman wrote:
> On Mon, Jun 7, 2021 at 12:24 PM Tim wrote:
>> I will, I believe, need to declare - place - MCAN related structures such
>> that they (or at least some elements of them) are in SRAM.
>>
> Yes. It is possible. It is done by adding attributes in the code which
> tell the compiler that an object should be located at a particular
> address or section.

I have added this to my linker script (and other variations on that
theme, all of which compile OK with no warnings or errors)

 .isramdata :
 {
 } > isram

and declared

static uint32_tg_mcan0_msgram[MCAN0_MSGRAM_WORDS]
__attribute__((section(".isramdata"))) = {0};
But it does not place the array in isram :(
system.map states: 20053fc4 D g_mcan0_msgram
which is confirmed by the debugger and an info debug message
Is there anything overruling this? Or a silly mistake, given my
inexperience with linker scripts?
Any guidance much appreciated!

RE: Port of project from NuttX 7.30 to 10.1 RC1: Unexpected IRQ

[David Sidrane]

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 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.

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 still similar to a recent one.

Sebastien

Le 26/05/2021 à 18:08, raiden00pl a écrit :
> 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 2021 o 17:21 Sebastien Lorquet 
> napisał(a):
>
>> 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...
>> stm32_netinitialize: PHY reset done.
>> stm32_netinitialize: Configuring PHY int
>> F
>> mm_free: Freeing 0x70fb460b
>> irq_unexpected_isr: ERROR irq: 3
>> up_assert: Assertion failed at file:irq/irq_unexpectedisr.c line: 50
>> up_registerdump: R0: 0001 2000737c c0f2 08000101 
>>   200073c8
>> up_registerdump: R8:     
>> 200073c8 080126ad 080126f8
>> up_registerdump: xPSR: 2100 PRIMASK:  CONTROL: 
>> up_registerdump: EXC_RETURN: fff9
>> up_dumpstate: sp: 200072c8
>> up_dumpstate: stack base: 20007078
>> up_dumpstate: stack size: 0400
>>
>> The fact that mm_initialize only shows one region is weird... where is
>> the heap for the main RAM at 0x2000?
>>
>> the mm_free(0x70fb460b) is not what causes the hardfault (it comes
>> later), but what the hell is is this invalid address!
>>
>> This is the first call to mm_free, here is the backtrace:
>>
>> Breakpoint 1, mm_free (heap=0x200060b4 , mem=0x70fb460b) at
>> mm_heap/mm_free.c:85
>> 85if (!mem)
>> (gdb) bt
>> #0  mm_free (heap=0x200060b4 , mem=0x70fb460b) at
>> mm_heap/mm_free.c:85
>> #1  0x0801264a in mm_free_delaylist (heap=0x200060b4 ) at
>> mm_heap/mm_malloc.c:82
>> #2  0x08012672 in mm_malloc (heap=0x200060b4 , size=24) at
>> mm_heap/mm_malloc.c:115
>> #3  0x08012a32 in mm_zalloc (heap=0x200060b4 , size=24) at
>> mm_heap/mm_zalloc.c:45
>> #4  0x080123ac in zalloc (size=24) at umm_heap/umm_zalloc.c:68
>> #5  0x080399fa in inode_alloc (name=0x8059a78 "") at
>> inode/fs_inodereserve.c:78
>> #6  0x08039a5c in inode_root_reserve () at inode/fs_inodereserve.c:129
>> #7  0x080398cc in inode_initialize () at inode/fs_inode.c:92
>> #8  0x08039284 in fs_initialize () at fs_initialize.c:47
>> #9  0x08007eb4 in nx_start () at init/nx_start.c:600
>> #10 0x0800421e in __start () at chip/stm32_start.c:338
>>
>> As previously analyzed, this happens in fs_initialize through
>> inode_root_reserve, so I was on the right track.
>>
>> Caller shows mm_free called with that weird address:
>>
>> (gdb) f 1
>> #1  0x0801264a in mm_free_delaylist (heap=0x200060b4 ) at
>> mm_heap/mm_malloc.c:82
>> 82mm_free(heap, address);
>> (gdb) list
>> 77
>> 78/* The address should always be non-NULL since that was
>> checked in the
>> 79 * 'while' condition above.
>> 80 */
>> 81
>> 82mm_free(heap, address); <-- address == 0x70fb460b
>> 83  }
>> 84  #endif
>> 85  }
>> 86
>>
>> (gdb) print _mmheap
>> $3 = (struct mm_heap_s *) 0x200060b4 
>> (gdb) print g_mmheap
>> $4 = {mm_impl = 0x0}
>>
>> this is not good!
>>
>> This is not a timing or IRQ related issue but a heap issue.
>>
>> R15 = 080126f8 translates to here:
>>
>>
>> https://github.com/apache/incubator-nuttx/blob/master/mm/mm_heap/mm_malloc.c#L199
>>
>> => this free() has corrupted a badly initialized heap, and the next
>> malloc fails, giving a hardfault because that address is invalid.
>>
>> Horrific mess!
>>
>> ==>
>>
>> I think that my old board code does not initialize the board properly, I
>> probably have to check for differences between my code and the
>> stm32f429i-disco built-in board (on which I based my board).
>>
>> Sebastien
>>
>> Le 25/05/2021 à 21:26, Nathan Hartman a écrit :
>>> 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 

RE: (Standard | Recommended) way to create NuttX applications

[David Sidrane]

Yes you can,

Just call the app.

Create and app. Call it what you like. user_start etc.

Set

CONFIG_USERMAIN_STACKSIZE=1100
CONFIG_USER_ENTRYPOINT="user_start"

Int user_start(int argc, char *argv[])
{
 return ...;
}


CONFIG_USERMAIN_STACKSIZE=1100
CONFIG_USER_ENTRYPOINT="pigs_can_fly "

Int pigs_can_fly (int argc, char *argv[])
{
return ...;
}

-Original Message-
From: Gregory Nutt [mailto:spudan...@gmail.com]
Sent: Saturday, May 22, 2021 7:12 AM
To: dev@nuttx.apache.org
Subject: Re: (Standard | Recommended) way to create NuttX applications


> This question is more of a curiosity. Which is the most used, or
> recommended to implement and deploy an application in a NuttX
> environment?
>
> I saw that it is possible to have several applications to be called by
> NuttShell, and you can set applications to run when NuttShell starts.
>
> It is also possible to have a standalone application without NutShell.
>
> Is there any recommended approach?

No, NuttX is an OS.  You can setup your applications in any that you
would like.

PX4 uses an NSH startup script to bring up their system.

RE: Ethernet cable (network interface availability) detection

[David Sidrane]

This https://github.com/apache/incubator-nuttx/pull/1924 was merged. It adds
the polling.

This is the app https://github.com/PX4/NuttX-apps/pull/8  does the rest.

It was not upstreamed because it was not everything others wanted and I
could not test what they wanted.

David

-Original Message-
From: Gregory Nutt [mailto:spudan...@gmail.com]
Sent: Wednesday, May 19, 2021 2:56 PM
To: dev@nuttx.apache.org
Subject: Re: Ethernet cable (network interface availability) detection


> Considering this scenario, is there any alternative approach that I
> could use to have this detection? Polling the phy, or something
> similar?

As I recall, David Sidrane submitted a PR to do just this but it was not
incoporated.  I don't recall why.   I recall having some concerns that
polling the PHY in maintenance mode would interfere with normal
operational mode, but I think David demonstrated that there was not an
issue with that.

I think these:

https://github.com/apache/incubator-nuttx-apps/pull/402

https://github.com/apache/incubator-nuttx-apps/pull/415

RE: RE: RE: Nuttx FAT32 issues - corrupted files, wrongly stated free clusters by statfs

[David Sidrane]

Hi Reto,

The multiblock is a disable so if CONFIG_MMCSD_MULTIBLOCK_DISABLE=y is not
in the config it is using multiblock

However, that is only for the SDMMC driver. What I was thinking was [1],[2]
for the SDMMC driver not the SPI one.

[1] https://github.com/apache/incubator-nuttx/pull/3669
[2] https://github.com/PX4/PX4-Autopilot/issues/17442#issuecomment-835303021


David

-Original Message-
From: Reto Gähwiler [mailto:gret.hexa...@gmail.com]
Sent: Wednesday, May 19, 2021 8:21 AM
To: dev@nuttx.apache.org
Subject: Re: RE: RE: Nuttx FAT32 issues - corrupted files, wrongly stated
free clusters by statfs

Hey again,

About the requested configuration of the SD-Card, here we go:
  CONFIG_MMCSD=y
  CONFIG_MMCSD_SPI=y
  CONFIG_MMCSD_SPICLOCK=2500

About the multiblock, I don't think we are using that. Let me know how I
could recognise it if not in the config.

Thanks, Reto

On 2021/05/19 12:13:35, David Sidrane  wrote:
> Hi Reto,
>
> What is the clock rate to the card and is multiblock enabled?
>
> David
>
> -Original Message-
> From: Reto Gähwiler [mailto:gret.hexa...@gmail.com]
> Sent: Wednesday, May 19, 2021 5:08 AM
> To: dev@nuttx.apache.org
> Subject: Re: RE: Nuttx FAT32 issues - corrupted files, wrongly stated free
> clusters by statfs
>
> Hi David,
>
> It is running on an STM32h743zi version V or Y. The SD-card in use is a
> SwissBit S-45u.
>
> Reto
>
> On 2021/05/19 11:11:22, David Sidrane  wrote:
> > hi Reto,
> >
> > What SoC is this on? What type of card are you using?
> >
> > David
> >
> > -Original Message-
> > From: Reto Gähwiler [mailto:gret.hexa...@gmail.com]
> > Sent: Wednesday, May 19, 2021 3:22 AM
> > To: dev@nuttx.apache.org
> > Subject: Re: Nuttx FAT32 issues - corrupted files, wrongly stated free
> > clusters by statfs
> >
> > Hello Jukka,
> >
> > Thanks for your quick reaction. I applied your PR to our "outdated"
> > nuttx.
> > Unfortunately, it did not show any impact on the statfs behaviour if the
> > card is corrupted. Though, meanwhile I do have hands on two images.
> >
> > #1 the mentioned one. Although, the files/dirs are all deleted. But
> > still
> > same behvaiour and a chkdsk error. statfs reports 703 MB free while the
> > sd-card was deleted!
> >
> > #2 Having the file structure in place and contains plenty of logfiles.
> > Many
> > of them with the mentioned corruptions. The card is filled to 100%. But
> > here
> > the behaviour is slightly different. Checking the FSINFO block and then
> > removing some files under Windows doesn't impact the FSINFO section. But
> > once inserted to the device statfs reports the correct size and updates
> > the
> > FSINFO section. However, the card also shows corruptions if chkdsk is
> > applied to it.
> > This behaviour is identical before and after applying your PR.
> >
> > Brgds, Reto
> >
> > On 2021/05/18 19:55:06, Jukka Laitinen  wrote:
> > > Hi,
> > >
> > > There seems to be a bug in sector calculation which may trigger with
> > > e.g. corrupted fs. I just made a PR for this,
> > >
> > > https://github.com/apache/incubator-nuttx/pull/3740
> > >
> > > But I really don't know if this is related to your issues, this is
> > > just
> > > something that suddenly popped up elsewhere.
> > >
> > > -Jukka
> > >
> > >
> > > On 18.5.2021 16.10, Reto Gähwiler wrote:
> > > > Dear All,
> > > >
> > > > First of all, in case a similar thread pops-up authored by myself,
> > > > please
> > > > ignore.
> > > >
> > > > Recently we discovered some issues with the FAT32 partition on the
> > > > SD-Card
> > > > used in our device running on nuttx. There are actually a bunch of
> > > > issues
> > > > we are strugle to understand related to the filesystem.
> > > > The issue discovered recently is, that a statfs call won't return
> > > > the
> > > > true
> > > > number of free clusters. It rather returns what ever is in the FS
> > > > INFO
> > > > section of the FAT32 partition. Inserting such a "corrupted" card
> > > > into
> > > > an
> > > > SD-Card reader and mounting it to Windows shows following:
> > > >
> > > > #1 Windows file explorer reports the correct free space.
> > > > #2 Comparing the free space in file explorer and looging at FS INFO
> > > > section
> > > > wit

RE: RE: Nuttx FAT32 issues - corrupted files, wrongly stated free clusters by statfs

[David Sidrane]

Hi Reto,

What is the clock rate to the card and is multiblock enabled?

David

-Original Message-
From: Reto Gähwiler [mailto:gret.hexa...@gmail.com]
Sent: Wednesday, May 19, 2021 5:08 AM
To: dev@nuttx.apache.org
Subject: Re: RE: Nuttx FAT32 issues - corrupted files, wrongly stated free
clusters by statfs

Hi David,

It is running on an STM32h743zi version V or Y. The SD-card in use is a
SwissBit S-45u.

Reto

On 2021/05/19 11:11:22, David Sidrane  wrote:
> hi Reto,
>
> What SoC is this on? What type of card are you using?
>
> David
>
> -Original Message-
> From: Reto Gähwiler [mailto:gret.hexa...@gmail.com]
> Sent: Wednesday, May 19, 2021 3:22 AM
> To: dev@nuttx.apache.org
> Subject: Re: Nuttx FAT32 issues - corrupted files, wrongly stated free
> clusters by statfs
>
> Hello Jukka,
>
> Thanks for your quick reaction. I applied your PR to our "outdated" nuttx.
> Unfortunately, it did not show any impact on the statfs behaviour if the
> card is corrupted. Though, meanwhile I do have hands on two images.
>
> #1 the mentioned one. Although, the files/dirs are all deleted. But still
> same behvaiour and a chkdsk error. statfs reports 703 MB free while the
> sd-card was deleted!
>
> #2 Having the file structure in place and contains plenty of logfiles.
> Many
> of them with the mentioned corruptions. The card is filled to 100%. But
> here
> the behaviour is slightly different. Checking the FSINFO block and then
> removing some files under Windows doesn't impact the FSINFO section. But
> once inserted to the device statfs reports the correct size and updates
> the
> FSINFO section. However, the card also shows corruptions if chkdsk is
> applied to it.
> This behaviour is identical before and after applying your PR.
>
> Brgds, Reto
>
> On 2021/05/18 19:55:06, Jukka Laitinen  wrote:
> > Hi,
> >
> > There seems to be a bug in sector calculation which may trigger with
> > e.g. corrupted fs. I just made a PR for this,
> >
> > https://github.com/apache/incubator-nuttx/pull/3740
> >
> > But I really don't know if this is related to your issues, this is just
> > something that suddenly popped up elsewhere.
> >
> > -Jukka
> >
> >
> > On 18.5.2021 16.10, Reto Gähwiler wrote:
> > > Dear All,
> > >
> > > First of all, in case a similar thread pops-up authored by myself,
> > > please
> > > ignore.
> > >
> > > Recently we discovered some issues with the FAT32 partition on the
> > > SD-Card
> > > used in our device running on nuttx. There are actually a bunch of
> > > issues
> > > we are strugle to understand related to the filesystem.
> > > The issue discovered recently is, that a statfs call won't return the
> > > true
> > > number of free clusters. It rather returns what ever is in the FS INFO
> > > section of the FAT32 partition. Inserting such a "corrupted" card into
> > > an
> > > SD-Card reader and mounting it to Windows shows following:
> > >
> > > #1 Windows file explorer reports the correct free space.
> > > #2 Comparing the free space in file explorer and looging at FS INFO
> > > section
> > > with "Active - Disk Editor" doesn't line up. Windows wouldn't write
> > > any
> > > longer the FS INFO section on that card. Even if all the files/dires
> > > are
> > > wiped from the card.
> > > #3 Whenever files are added / removed under nuttx the FS INFO section
> > > would
> > > be updated by nuttx, but to the wrong number since the base is wrong.
> > > #4 Mounting the card to linux and properly unmount it might actually
> > > fix
> > > the issue. But not always!
> > > #5 Quick format the card resolved the issue too. Windows would once
> > > again
> > > write the FS INFO section and nuttx would shows the correct free
> > > space.
> > > #5 Running a "chkdsk /f" under windows on that broken SD-Card fixes
> > > the
> > > issue too. Reporting a broken file in a root folder on that card.
> > >
> > > We indeed had issues with corrupted files in the past. Usually in the
> > > logging directory, which is accessed most. How they corrupt we do not
> > > know.
> > > The corruption is recognised in the following ways:
> > >
> > > #A cryptic and too long file names, we only make use of short file
> > > names
> > > (8.3)
> > > #B files whcih became folders
> > > #C sizes which are not possible
> > > #D combinations of the above
&g

RE: Nuttx FAT32 issues - corrupted files, wrongly stated free clusters by statfs

[David Sidrane]

hi Reto,

What SoC is this on? What type of card are you using?

David

-Original Message-
From: Reto Gähwiler [mailto:gret.hexa...@gmail.com]
Sent: Wednesday, May 19, 2021 3:22 AM
To: dev@nuttx.apache.org
Subject: Re: Nuttx FAT32 issues - corrupted files, wrongly stated free
clusters by statfs

Hello Jukka,

Thanks for your quick reaction. I applied your PR to our "outdated" nuttx.
Unfortunately, it did not show any impact on the statfs behaviour if the
card is corrupted. Though, meanwhile I do have hands on two images.

#1 the mentioned one. Although, the files/dirs are all deleted. But still
same behvaiour and a chkdsk error. statfs reports 703 MB free while the
sd-card was deleted!

#2 Having the file structure in place and contains plenty of logfiles. Many
of them with the mentioned corruptions. The card is filled to 100%. But here
the behaviour is slightly different. Checking the FSINFO block and then
removing some files under Windows doesn't impact the FSINFO section. But
once inserted to the device statfs reports the correct size and updates the
FSINFO section. However, the card also shows corruptions if chkdsk is
applied to it.
This behaviour is identical before and after applying your PR.

Brgds, Reto

On 2021/05/18 19:55:06, Jukka Laitinen  wrote:
> Hi,
>
> There seems to be a bug in sector calculation which may trigger with
> e.g. corrupted fs. I just made a PR for this,
>
> https://github.com/apache/incubator-nuttx/pull/3740
>
> But I really don't know if this is related to your issues, this is just
> something that suddenly popped up elsewhere.
>
> -Jukka
>
>
> On 18.5.2021 16.10, Reto Gähwiler wrote:
> > Dear All,
> >
> > First of all, in case a similar thread pops-up authored by myself,
> > please
> > ignore.
> >
> > Recently we discovered some issues with the FAT32 partition on the
> > SD-Card
> > used in our device running on nuttx. There are actually a bunch of
> > issues
> > we are strugle to understand related to the filesystem.
> > The issue discovered recently is, that a statfs call won't return the
> > true
> > number of free clusters. It rather returns what ever is in the FS INFO
> > section of the FAT32 partition. Inserting such a "corrupted" card into
> > an
> > SD-Card reader and mounting it to Windows shows following:
> >
> > #1 Windows file explorer reports the correct free space.
> > #2 Comparing the free space in file explorer and looging at FS INFO
> > section
> > with "Active - Disk Editor" doesn't line up. Windows wouldn't write any
> > longer the FS INFO section on that card. Even if all the files/dires are
> > wiped from the card.
> > #3 Whenever files are added / removed under nuttx the FS INFO section
> > would
> > be updated by nuttx, but to the wrong number since the base is wrong.
> > #4 Mounting the card to linux and properly unmount it might actually fix
> > the issue. But not always!
> > #5 Quick format the card resolved the issue too. Windows would once
> > again
> > write the FS INFO section and nuttx would shows the correct free space.
> > #5 Running a "chkdsk /f" under windows on that broken SD-Card fixes the
> > issue too. Reporting a broken file in a root folder on that card.
> >
> > We indeed had issues with corrupted files in the past. Usually in the
> > logging directory, which is accessed most. How they corrupt we do not
> > know.
> > The corruption is recognised in the following ways:
> >
> > #A cryptic and too long file names, we only make use of short file names
> > (8.3)
> > #B files whcih became folders
> > #C sizes which are not possible
> > #D combinations of the above
> >
> > Our application supervises the SD-Card with statfs and removes files
> > once
> > we hit a quota of 0.85. Therefore, the card is not filling up. However,
> > the
> > most recent recognition of this behvaiour was due to an application bug
> > which allowed the card to fill up under some circumstances.
> > Playing around with a quickformated SD-Card, filled up with data and
> > trying
> > to retrigger the issue revealed that I never get the ENOSPC but only EIO
> > once the card is full! But never managed to get the statfs issue.
> > For the logging we use the fstream family (fopen, fwrite, fread, fflush,
> > fsync) commands. For config files and other things also the low level
> > read/write are used.
> >
> > One more thing, among all the logging files we once in a while have
> > corrupted file content. Typically that is a skipped byte or doubled byte
> > (we use protobuf and can see that encoding the binary). This seems to
> > happen during reading but also writing the file.
> >
> > At the moment we didn't investigate the fat driver of nuttx but rather
> > tried to analyse the problem. And now we have a bunch of question marks.
> >
> > #1 Has anyone recongised similar issues?
> > #2 Does anyone know a tool which can be used in nuttx equivalent to
> > chkdsk
> > under windows? Or do quick format?
> > #3 Why is there no ENOSPC but EIO once the card is full?
> > #4 

RE: NuttX (Online) Workshop 2021 (call for event team members)

[David Sidrane]

Please count me in.

-Original Message-
From: alin.jerpe...@sony.com [mailto:alin.jerpe...@sony.com]
Sent: Tuesday, May 18, 2021 1:54 AM
To: dev@nuttx.apache.org
Subject: NuttX (Online) Workshop 2021 (call for event team members)

Hi all,

Yesterday me and Alan were talking about the plans for the NuttX 2021
workshop and we were thinking that we should see if there are other people
interested to be part of the event team.
If you are interested to be part of the event team please replay to this
mail and we will invite you to the online meeting.
Regards
Alin

RE: [VOTE] Apache NuttX 10.1.0 (incubating) RC0 release

[David Sidrane]

Yes! I just lit the label (backport/10.1)

-Original Message-
From: Gustavo Henrique Nihei [mailto:ghni...@gmail.com]
Sent: Wednesday, April 28, 2021 5:58 AM
To: dev@nuttx.apache.org
Subject: Re: [VOTE] Apache NuttX 10.1.0 (incubating) RC0 release

Hi folks,

I believe we should consider backporting the fix from this PR into the
10.1.0 release:
https://github.com/apache/incubator-nuttx/pull/3614

It fixes a side effect from the refactoring of the stack architecture
due to a wrong stack alignment for RISC-V chips.

Best regards,
Gustavo.

On Mon, Apr 26, 2021 at 5:58 AM  wrote:
>
> Hi Brenan,
>
> We still have the following commit that is not resolved and I think that
> it is better to hold the release until it is ready for emerge
> https://github.com/apache/incubator-nuttx/pull/3601
>
> Regards
> Alin
>
> -Original Message-
> From: Alin Jerpelea 
> Sent: den 22 april 2021 16:14
> To: dev@nuttx.apache.org
> Subject: Re: [VOTE] Apache NuttX 10.1.0 (incubating) RC0 release
>
> It is perfect timing!
>
> I will cut RC1 with the fixes tonight
>
> Thanks
> Alin
>
> On Thu, Apr 22, 2021, 16:12 Nathan Hartman 
> wrote:
>
> > On Thu, Apr 22, 2021 at 2:54 AM Alin Jerpelea 
> > wrote:
> >
> > > Hi Brennan,
> > > I think that we should backport them and I will cut RC1 Thanks Alin
> >
> >
> >
> > If I'm not too late, I fixed up the ReleaseNotes a little bit in
> > PR-3570
> >
> >
> >
> >
> > >
> > >
> > > On Thu, Apr 22, 2021, 08:30 Brennan Ashton
> > > 
> > > wrote:
> > >
> > > > Alin,
> > > > I think we should consider if we want to backport these into the
> > > > 10.1.0 release.  I am still running more tests myself on all the
> > > > hardware I have, but these seemed important to at least consider.
> > > > https://urldefense.com/v3/__https://github.com/apache/incubator-nu
> > > > ttx/pull/3586__;!!JmoZiZGBv3RvKRSx!rb2nGxDcx1NeBVx6ZgXhc6ZY2nV6G_l
> > > > kT8Y8QJWo9Nv_bGYGjtgmeOc3mRLLOLl7Nw$
> > > > https://urldefense.com/v3/__https://github.com/apache/incubator-nu
> > > > ttx/pull/3580__;!!JmoZiZGBv3RvKRSx!rb2nGxDcx1NeBVx6ZgXhc6ZY2nV6G_l
> > > > kT8Y8QJWo9Nv_bGYGjtgmeOc3mRKshpGeRw$
> > > >
> > > > --Brennan
> > > >
> > > > On Sun, Apr 18, 2021 at 7:06 AM Alin Jerpelea 
> > > wrote:
> > > > >
> > > > > Hello all,
> > > > > Apache NuttX (Incubating) 10.1.0 RC0 has been staged under [1]
> > > > > and
> > it's
> > > > > time to vote on accepting it for release. If approved we will
> > > > > seek final release approval from the IPMC. Voting will be open for
> > > > > 72hr.
> > > > >
> > > > > A minimum of 3 binding +1 votes and more binding +1 than binding
> > > > > -1
> > are
> > > > > required to pass.
> > > > >
> > > > > The Apache requirements for approving a release can be found
> > > > > here [3] "Before voting +1 [P]PMC members are required to
> > > > > download the signed source code package, compile it as provided,
> > > > > and test the resulting executable on their own platform, along
> > > > > with also verifying that the package meets the requirements of the
> > > > > ASF policy on releases."
> > > > >
> > > > > A document to walk through some of this process has been
> > > > > published on our project wiki and can be found here [4].
> > > > >
> > > > > [ ] +1 accept (indicate what you validated - e.g. performed the
> > non-RM
> > > > > items in [4])
> > > > > [ ] -1 reject (explanation required)
> > > > >
> > > > > Thank you all,
> > > > > Alin Jerpelea
> > > > >
> > > > > SCM Information:
> > > > >   Release tag: nuttx-10.1.0-RC0
> > > > >   Hash for the release incubating-nuttx tag:
> > > > > f380c919f04d5ee88e0a83f5632cc83af503664f
> > > > >   Hash for the release incubating-nuttx-apps tag:
> > > > > 4348d91d1356335483089c3865282d80f13bedcd
> > > > >
> > > > > [1]
> > https://urldefense.com/v3/__https://dist.apache.org/repos/dist/dev/inc
> > ubator/nuttx/10.1.0-RC0/__;!!JmoZiZGBv3RvKRSx!rb2nGxDcx1NeBVx6ZgXhc6ZY
> > 2nV6G_lkT8Y8QJWo9Nv_bGYGjtgmeOc3mRIUEGmDag$
> > > > > [2]
> > > >
> > >
> > https://urldefense.com/v3/__https://raw.githubusercontent.com/apache/i
> > ncubator-nuttx/nuttx-10.1.0-RC0/ReleaseNotes__;!!JmoZiZGBv3RvKRSx!rb2n
> > GxDcx1NeBVx6ZgXhc6ZY2nV6G_lkT8Y8QJWo9Nv_bGYGjtgmeOc3mRJlgBtnkg$
> > > > > [3]
> > > > > https://urldefense.com/v3/__https://www.apache.org/dev/release.h
> > > > > tml*approving-a-release__;Iw!!JmoZiZGBv3RvKRSx!rb2nGxDcx1NeBVx6Z
> > > > > gXhc6ZY2nV6G_lkT8Y8QJWo9Nv_bGYGjtgmeOc3mRJEiqu7OA$
> > > > > [4]
> > > >
> > >
> > https://urldefense.com/v3/__https://cwiki.apache.org/confluence/displa
> > y/NUTTX/Validating*a*staged*Release__;Kysr!!JmoZiZGBv3RvKRSx!rb2nGxDcx
> > 1NeBVx6ZgXhc6ZY2nV6G_lkT8Y8QJWo9Nv_bGYGjtgmeOc3mRJsl8kw8w$
> > > >
> > >
> >



-- 
Gustavo Henrique Nihei

RE: IMXRT1064 and 2 Ethernet interfaces

[David Sidrane]

Hi Vadim ,

This sounds familiar.Please check if that code is a copy of the Kinetis
driver. If so, see the changes that were done to it in
https://github.com/apache/incubator-nuttx/pull/1273

David

-Original Message-
From: Вадим Ястребов [mailto:woody_haw...@mail.ru.INVALID]
Sent: Friday, April 16, 2021 5:50 AM
To: dev
Subject: IMXRT1064 and 2 Ethernet interfaces


Hello everyone,

I have encountered a problem related to initializing 2 Ethernet interfaces
on IMXRT1064 and I was wondering if you have any idea where to look for
solutions.

Sometimes both interfaces work fine. Sometimes, when initializing the second
interface with ifconfig followed by ifup, the first one dies about 10
seconds later. Sometimes the first one stops responding to ping and the
debug output is showing me "ipv4_input: WARNING: Not destined for us; not
forwardable... Dropping!" and "ipv4_input: WARNING: IP packet shorter than
length in IP header"... Although, I am not very sure if this debug output is
related to my problem. Maybe it's something else I still need to dig
deeper into it!

Any suggestions will be greatly appreciated!

Best Regards,
Vadim Yastrebov

RE: CAN on STM32H7 platforms under NuttX

[David Sidrane]

Roberto

There is a DRAFT PR https://github.com/apache/incubator-nuttx/pull/2987

David
-Original Message-
From: Roberto Bucher [mailto:roberto.buc...@supsi.ch]
Sent: Wednesday, April 14, 2021 6:18 AM
To: dev@nuttx.apache.org
Subject: CAN on STM32H7 platforms under NuttX

Hi

For a bachelor project with a student, which will start on may 2021, I
have to implement a CAN communication between a STM32H743ZI2 board and 2
STM32F446 boards. I'd like to propose to my student to work with
micro-ROS and NuttX on both platforms.

Basically it seems that the CAN bus files are not yet implemented in the
NuttX tree for the STM32H7 board. Did somebody work on implementation of
CAN bus for the STM32H7 architecture?

Thanks in advance

Roberto

RE: How to ensure HEAP will not overlap static DMA buffer?

[David Sidrane]

That may be true, but I think that the dependencies and composition of a
board can and should be defined in the Kconfig. Since the board that are in
tree in NuttX are standard, it would need to be extensible to support
custom HW and the use cases you list. But again that is not compile time,
it is link time and there are dependencies that need to be matained.



*From:* Fotis Panagiotopoulos [mailto:f.j.pa...@gmail.com]
*Sent:* Friday, March 26, 2021 9:46 AM
*To:* dev@nuttx.apache.org
*Subject:* Re: How to ensure HEAP will not overlap static DMA buffer?



Oh, sorry.

Attached again as .txt. Is it OK now?



> A tool that takes the Kconfig + chip+ memorymap and make a linker include
> file and the config code for the heap may be the way to go.



I am pretty sure that a "tool" will not be able to cover all use cases.

Over the years I had to make custom scripts to account for:

* Bootloaders

* Binary blops

* Firmware headers

* ROM files

* DMA buffers

* External memories

 etc etc..



Do you believe that a tool can be made that can handle everything?





Στις Παρ, 26 Μαρ 2021 στις 6:37 μ.μ., ο/η David Sidrane <
david.sidr...@nscdg.com> έγραψε:

I am just thinking out load...

I agree this has to come from one place. But I do think it is just the
linker file.

Currently we have
The arch memroymap h files have the base addresses, sizes  - This is the
Reference manuals counterpart, it covers all the sub members of the chips)
The chip.h files  that has sizes  - This is the Data Sheet counterpart, it
covers one or more of the sub members of the chips)
The Kconfig - More flexible from a users stand point.
The heap c files - buried semantics - not good
linker file - the boards usage specific.

I like using the linker file, but Kconfig is build time - no file
modification

Just moving things to the linker file does not fix the ordering or adding
issues. (it is link time not compile time)

A tool that takes the Kconfig + chip+ memorymap and make a linker include
file and the config code for the heap may be the way to go.

David


-Original Message-
From: Fotis Panagiotopoulos [mailto:f.j.pa...@gmail.com]
Sent: Friday, March 26, 2021 9:17 AM
To: dev@nuttx.apache.org
Subject: Re: How to ensure HEAP will not overlap static DMA buffer?

I face similar problems (with a different use case) on an STM32F4.
The thing is that although the linker script belongs to the board logic and
thus it is freely customizable, the heap regions are hard-coded in the arch
files.

So, I started working on PR #2277 (
https://github.com/apache/incubator-nuttx/pull/2277), but unfortunately I
had to pause the development on this.
The idea is similar to what you describe here. Everything can be defined in
the linkerscript (addresses, order, sizeses etc).

I was thinking a lot of any alternatives on this. I came to the conclusion
that Kconfig is the wrong tool for this job.
You lose all compile-time (and CI) checks and can easily be misconfigured.
I am also afraid that we will end up with a few dozen "hacks" like above or
like STM32_CCMEXCLUDE (I never liked this option).
And no matter what you do, you will never be able to satisfy any crazy
memory mappings that any project may need.

A similar issue to this is Issue #2001 (
https://github.com/apache/incubator-nuttx/issues/2001).
This was my first crash while trying out NuttX :)
In short, there is the assumption that the main stack will always reside
between BSS and Heap, again being very restrictive.


Στις Παρ, 26 Μαρ 2021 στις 5:46 μ.μ., ο/η Nathan Hartman <
hartman.nat...@gmail.com> έγραψε:

> On Fri, Mar 26, 2021 at 11:41 AM Gregory Nutt  wrote:
>
> > Missing bit of logic:
> >
> > >> Speaking of the linker, is there a way to use a combination of the
> > >> linker script and __attribute__ incantations in the code to detect
> > >> automatically the size that g_sram4_reserve should be and entirely
> > >> eliminate the need for the user to specify the start and end of each
> > >> region in Kconfig?
> > >
> > > Are you thinking of something like this in the linker script:
> > >
> > > .sram4_reserve :
> > > {
> > >   _sram4_reserve_begin = ABSOLUTE(.);
> > >   *(.sram4)
> > >   _sram4_reserve_end = ABSOLUTE(.);
> > > }
> > >
> > > And in the C code:
> > >
> > We need to lie to C and tell it what to think those symbols are:
> >
> > EXTERN const uint32_t _sram4_reserve_begin
> > EXTERN const uint32_t _sram4_reserve_begin
>
>
>
> Ah, yes, otherwise those symbols would be undefined. Later the linker will
> resolve them to the correct addresses.
>
>
> > #define SRAM4_RESERVE_BEGIN &_sram4_reserve_begin
> > > #define SRAM4_RESERVE_END &_sram4_reserve_end

RE: How to ensure HEAP will not overlap static DMA buffer?

[David Sidrane]

I am just thinking out load...

I agree this has to come from one place. But I do think it is just the
linker file.

Currently we have
The arch memroymap h files have the base addresses, sizes  - This is the
Reference manuals counterpart, it covers all the sub members of the chips)
The chip.h files  that has sizes  - This is the Data Sheet counterpart, it
covers one or more of the sub members of the chips)
The Kconfig - More flexible from a users stand point.
The heap c files - buried semantics - not good
linker file - the boards usage specific.

I like using the linker file, but Kconfig is build time - no file
modification

Just moving things to the linker file does not fix the ordering or adding
issues. (it is link time not compile time)

A tool that takes the Kconfig + chip+ memorymap and make a linker include
file and the config code for the heap may be the way to go.

David


-Original Message-
From: Fotis Panagiotopoulos [mailto:f.j.pa...@gmail.com]
Sent: Friday, March 26, 2021 9:17 AM
To: dev@nuttx.apache.org
Subject: Re: How to ensure HEAP will not overlap static DMA buffer?

I face similar problems (with a different use case) on an STM32F4.
The thing is that although the linker script belongs to the board logic and
thus it is freely customizable, the heap regions are hard-coded in the arch
files.

So, I started working on PR #2277 (
https://github.com/apache/incubator-nuttx/pull/2277), but unfortunately I
had to pause the development on this.
The idea is similar to what you describe here. Everything can be defined in
the linkerscript (addresses, order, sizeses etc).

I was thinking a lot of any alternatives on this. I came to the conclusion
that Kconfig is the wrong tool for this job.
You lose all compile-time (and CI) checks and can easily be misconfigured.
I am also afraid that we will end up with a few dozen "hacks" like above or
like STM32_CCMEXCLUDE (I never liked this option).
And no matter what you do, you will never be able to satisfy any crazy
memory mappings that any project may need.

A similar issue to this is Issue #2001 (
https://github.com/apache/incubator-nuttx/issues/2001).
This was my first crash while trying out NuttX :)
In short, there is the assumption that the main stack will always reside
between BSS and Heap, again being very restrictive.


Στις Παρ, 26 Μαρ 2021 στις 5:46 μ.μ., ο/η Nathan Hartman <
hartman.nat...@gmail.com> έγραψε:

> On Fri, Mar 26, 2021 at 11:41 AM Gregory Nutt  wrote:
>
> > Missing bit of logic:
> >
> > >> Speaking of the linker, is there a way to use a combination of the
> > >> linker script and __attribute__ incantations in the code to detect
> > >> automatically the size that g_sram4_reserve should be and entirely
> > >> eliminate the need for the user to specify the start and end of each
> > >> region in Kconfig?
> > >
> > > Are you thinking of something like this in the linker script:
> > >
> > > .sram4_reserve :
> > > {
> > >   _sram4_reserve_begin = ABSOLUTE(.);
> > >   *(.sram4)
> > >   _sram4_reserve_end = ABSOLUTE(.);
> > > }
> > >
> > > And in the C code:
> > >
> > We need to lie to C and tell it what to think those symbols are:
> >
> > EXTERN const uint32_t _sram4_reserve_begin
> > EXTERN const uint32_t _sram4_reserve_begin
>
>
>
> Ah, yes, otherwise those symbols would be undefined. Later the linker will
> resolve them to the correct addresses.
>
>
> > #define SRAM4_RESERVE_BEGIN &_sram4_reserve_begin
> > > #define SRAM4_RESERVE_END &_sram4_reserve_end
> > >
> > > The implied size depends on the size of all .sram4 sections.  I assume
> > > this would be positioned at the beginning of SRAM4 and the size of the
> > > region that could be added to the heap would be SRAM4_RESERVE_END
> > > through SRAM_END.
> > >
> > You can see this same kind of thing in, for example,
> > arch/arm/src/common/arm_internal.h
>
>
>
> Great! Thanks
>
> Nathan
>

RE: How to ensure HEAP will not overlap static DMA buffer?

[David Sidrane]

Hi Nathan,

I just ran into this, this week on all the H7 boards in PX4.

This was broken by
https://github.com/apache/incubator-nuttx/pull/459/files#diff-8e09d7a85a1cc6cc65e0bb43d7aa751e3caaec9f9d5e824f9b741a1487ec9199L117-L138

I did not catch the implication of that change at the time.

The original idea we to leave sram4 out when the CONFIG_MM_REGIONS was 3

The side effect benefit of the ordering was that tasks allocated first used
DTCM :).

But that is not very deterministic. Adding the dtcm heap is a move in the
better direction. Then set CONFIG_MM_REGIONS to 1.

However, not having a "SPEED" parameter to allocate makes using the dtcm
very arch/chip specific.

As you have noted checking at build time only works for in tree
configurations. The quick fix to add an CONFIG_..._EXCLUDE_SRAM4... (naming
TBD) and light it in things that select BDMA to SRAM4 would a good to
addition, and help in some cases, but selecting it just on BDMA could be
wasteful.
Maybe that is just a warning if SRAM4 is added to the heap when BDMA is
enabled.

These more complex muti-power domain Soc, require more floor planning of
resource allocation on the board designer and users part.

I think a more flexible approach is would be to rework the heap addition
logic to be selectable and orderable.

Then a board designer can choose to add the RAM blocks to the heap and order
them as desired.

CONFIG_...ADD_ORDER_SRAM
CONFIG_... ADD_ORDER _SRAM12..
CONFIG_... ADD_ORDER _ SRAM3..
CONFIG_... ADD_ORDER _SRAM4..
CONFIG_... ADD_ORDER _DTCM..

(naming TBD)

0 is not used. 1 first added, N last added.

This gets defined into an array with the start addresses and lengths. The
code then processes them in a loop until all are added.

I think this would give us the all in one solution and not force the
solution back to calling add region in late init per board.

In the case of SRAM4 it is small and I do not think there is value in
carving it up with static and partial heap. (But when you are out of memory
times get desperate)

I spent quite a bit of time mulling over using the granual allocator and
placing the buffers in the drivers. My conclusion was this:
For the granual allocator you have to give it the static memory large enough
to meet ALL demand. (this creates a runtime size dependency the user has to
manage) After init, the memory will be given out to the drives and that is
dependent on device messages sizes (i.e MAX SPI payload which is for the
most part static, unless you have PNP SPI) So once the memory is allocated
out, it is the same as the static allocation of buffers in the drivers. It
is more code, more complexity, can fail at run time for out of memory or
DMA/Dcache alignment reasons. The compiler telling you SRAM4 is full is a
lot easier to debug :)
The other issues is there is no way to pass a buffer for 2 bytes to a driver
and DMA/Dcache validate it and fall back to non DMA. The in driver buffers
do add a mem copy but given the DMA/Dcache alignment issues, and after doing
the timing analysis is it very small addition compared to the actual IO
time.

David



-Original Message-
From: Nathan Hartman [mailto:hartman.nat...@gmail.com]
Sent: Thursday, March 25, 2021 4:28 PM
To: dev@nuttx.apache.org
Subject: How to ensure HEAP will not overlap static DMA buffer?

tl;dr: How do I statically allocate DMA buffers and prevent the heap
from overlapping them?

Details: On STM32H7, BDMA can only reach SRAM4 (64 KB starting at
0x3800:). The armv7m DCache line size means the buffers must be
allocated on a cache line boundary. So a DMA buffer must meet 2
requirements: (1) be in SRAM4, and (2) be aligned and padded to 32
byte increments.

Ok, I can do this easily with:

static volatile uint8_t my_bdma_buf[128] __attribute__ ((section
(".sram4"))) __attribute__ ((aligned (32)));

or equivalent.

But then the heap will overlap this memory and my buffer will be
clobbered because arch/arm/src/stm32h7/stm32_allocateheap.c
arm_addregion() does this:

addregion (SRAM4_START, SRAM4_END - SRAM4_START, "SRAM4");

Looking into it, I see that in arch/arm/src/stm32h7/stm32_spi.c,
g_spi6_txbuf[] and g_spi6_rxbuf[] are declared like this:

static uint8_t g_spi6_txbuf[SPI6_DMABUFSIZE_ADJUSTED]
SPI6_DMABUFSIZE_ALGN locate_data(".sram4");
static uint8_t g_spi6_rxbuf[SPI6_DMABUFSIZE_ADJUSTED]
SPI6_DMABUFSIZE_ALGN locate_data(".sram4");

So they will suffer that same problem. (I'm pretty sure that's a bug,
unless I missed something.)

I discovered this the hard way, i.e., on my board, NSH suddenly
wouldn't start. In reality, it does start but it turns out that when
it tries to print the greeting message, it fails on the very first
character ('\n') and exits. Why? I single-stepped all the way into the
guts of the serial logic, and found that in fs/vfs/fs_write.c,
file_write(), it fetches the inode and tests if it's valid (!inode ||
!inode->u.i_ops || !inode->u.i_ops->write) or returns -EBADF. That's
where it fails, because it seems that the inode is 

RE: Sleep Resolution

[David Sidrane]

I asked about HW because some of the new SPI controller IP have the delays
programmable in HW. One from CS active to clock/data and the other is inter
data delays.

Using HW SS and the timers it is built in.

The issue is on a shared bus. We would need to extend the SPI API to support
the settings.

David

-Original Message-
From: Grr [mailto:gebbe...@gmail.com]
Sent: Wednesday, March 24, 2021 10:52 AM
To: dev@nuttx.apache.org
Subject: Re: Sleep Resolution

This is a SocketCAN driver for MCP2515 with a new SPI system that
streamlines the select->write->read->deselect process and so exposes the
need to guarantee hold time between read and deselect and disable time
between deselect and next select

Looking at David's code, it seems the loop is the right answer. The DWT
cannot be used for a portable solution but maybe an inline function. Thanks
for the idea

I believe NOPs are optimized away but it seems asm("") or something close
to that is not

It would be nice to incorporate a general solution for this problem to the
Nuttx toolbox

El mié, 24 mar 2021 a las 11:24, David Sidrane ()
escribió:

> What HW is this on?
>
> -Original Message-
> From: Grr [mailto:gebbe...@gmail.com]
> Sent: Wednesday, March 24, 2021 10:09 AM
> To: dev@nuttx.apache.org
> Subject: Re: Sleep Resolution
>
> Thank you very much for your response
>
> What I'm trying to do is to generate hold and disable times for SPI CS,
> which should be about 50 ns
>
> I started by an empty for loop but it seems optimization gets rid of it (I
> haven't researched the issue properly). Then I thought a proper function
> would be better but got stuck in that expression "sleep resolution"
>
> For that scale (10 SYSCLK cycles), a loop is probably OK but I wanted to
> make sure there's not a more appropriate system tool
>
> El mié, 24 mar 2021 a las 10:46, Sara da Cunha Monteiro de Souza (<
> saramonteirosouz...@gmail.com>) escribió:
>
> > Hi Grr,
> >
> > I have never needed to use this function neither this range (ns).
> > But I used the usleep function which resolution is defined as
> > CONFIG_USEC_PER_TICK.
> > But maybe, in your case, for such range, you should consider using a
> > hardware timer or a Timer Hook.
> > Take a look at this wiki:
> > https://cwiki.apache.org/confluence/display/NUTTX/Short+Time+Delays
> >
> > Sara
> >
> > Em qua., 24 de mar. de 2021 às 13:37, Grr  escreveu:
> >
> > > Hello to all.
> > >
> > > Looking for the right way to create a _very_ short delay (10-100 ns),
> > > I
> > > found clock_nanosleep, whose description says:
> > >
> > > "The suspension time caused by this function may be longer than
> > > requested
> > > because the argument value is rounded up to an integer multiple of the
> > > sleep resolution"
> > >
> > > What is the sleep resolution and where/how is defined?
> > >
> > > TIA
> > > Grr
> > >
> >
>

RE: Sleep Resolution

[David Sidrane]

What HW is this on?

-Original Message-
From: Grr [mailto:gebbe...@gmail.com]
Sent: Wednesday, March 24, 2021 10:09 AM
To: dev@nuttx.apache.org
Subject: Re: Sleep Resolution

Thank you very much for your response

What I'm trying to do is to generate hold and disable times for SPI CS,
which should be about 50 ns

I started by an empty for loop but it seems optimization gets rid of it (I
haven't researched the issue properly). Then I thought a proper function
would be better but got stuck in that expression "sleep resolution"

For that scale (10 SYSCLK cycles), a loop is probably OK but I wanted to
make sure there's not a more appropriate system tool

El mié, 24 mar 2021 a las 10:46, Sara da Cunha Monteiro de Souza (<
saramonteirosouz...@gmail.com>) escribió:

> Hi Grr,
>
> I have never needed to use this function neither this range (ns).
> But I used the usleep function which resolution is defined as
> CONFIG_USEC_PER_TICK.
> But maybe, in your case, for such range, you should consider using a
> hardware timer or a Timer Hook.
> Take a look at this wiki:
> https://cwiki.apache.org/confluence/display/NUTTX/Short+Time+Delays
>
> Sara
>
> Em qua., 24 de mar. de 2021 às 13:37, Grr  escreveu:
>
> > Hello to all.
> >
> > Looking for the right way to create a _very_ short delay (10-100 ns), I
> > found clock_nanosleep, whose description says:
> >
> > "The suspension time caused by this function may be longer than
> > requested
> > because the argument value is rounded up to an integer multiple of the
> > sleep resolution"
> >
> > What is the sleep resolution and where/how is defined?
> >
> > TIA
> > Grr
> >
>

RE: Sleep Resolution

[David Sidrane]

Have a look at

https://github.com/PX4/PX4-Autopilot/blob/3ef93823f4b8f870b056549d321473a02fb69b1f/platforms/nuttx/src/px4/common/srgbled/srgbled.cpp#L112-L115


-Original Message-
From: Grr [mailto:gebbe...@gmail.com]
Sent: Wednesday, March 24, 2021 9:36 AM
To: dev@nuttx.apache.org
Subject: Sleep Resolution

Hello to all.

Looking for the right way to create a _very_ short delay (10-100 ns), I
found clock_nanosleep, whose description says:

"The suspension time caused by this function may be longer than requested
because the argument value is rounded up to an integer multiple of the
sleep resolution"

What is the sleep resolution and where/how is defined?

TIA
Grr

RE: avoiding pitfal of reuse of globals in FLAT mode?

[David Sidrane]

> For getopt() I see there's
even no standard getopt_r(), so we would have to provide our own, which
may not
be a bad idea.

Here is the one we have been using.

https://github.com/PX4/PX4-Autopilot/commit/eab32572f42f8e3e715b952512b6f5
df9041f848

https://github.com/PX4/PX4-Autopilot/blob/master/platforms/common/px4_geto
pt.c


David

-Original Message-
From: Matias N. [mailto:mat...@imap.cc]
Sent: Tuesday, March 23, 2021 6:18 PM
To: dev@nuttx.apache.org
Subject: Re: avoiding pitfal of reuse of globals in FLAT mode?



On Tue, Mar 23, 2021, at 22:09, Nathan Hartman wrote:
> On Tue, Mar 23, 2021 at 8:39 PM Matias N. mailto:matias%40imap.cc>> wrote:
>
> > Hi,
> > while using getopt() from a task started from NSH I realized
subsequent
> > calls reused the global optind and similar variables resulting in
different
> > results each time. I'm aware this is expected in FLAT mode and is
related
> > to the issue of static C++ constructors (they would only be called
once,
> > not every time the task is started).
> >
> > What I wonder is what could we do to avoid this common pitfall:
> > - document it somewhere (a common issues/troubleshooting section in
the
> > docs would be good to have anyways) and just accept the issue
> > - religiously initialize globals myself before being used (a pain,
error
> > prone, and a bit adhoc, working only for FLAT mode)
>
>
> When using globals, best practice is to make it really clear that the
> variables are global. Many programmers do this by prefixing global
variable
> names with g_*.
>
> I take a different approach: A long time ago, I started grouping all
> globals in a struct, which has one global instance called Global. It
makes
> it easy to find all globals, and furthermore at the start of the program
as
> a matter of policy the first thing I do is memset() the Global struct to
0.
> Yes, I know that is often redundant to the startup code, but in some
> situations the startup code doesn't initialize globals. The FLAT model
is
> one example of this (from the 2nd invocation onwards). I've seen other
> examples of this over the years. By memset()ing your globals at the
start
> of main() you can rest assured that the globals are in fact zeroed,
> regardless of whatever else happened before main(). It has another side
> benefit: with globals grouped this way, it becomes trivial to take a
> standalone program and turn it into a component of a larger program.
> tl;dr, this
> approach has worked great for me for a long time.

That sounds like a good approach.

>
> Caveat: It won't help if your program (or any API called by it) uses
> globals that are outside your control, and therefore, not initialized by
> you. :-/

Yes, my concern is about functions such as getopt(). If you just follow
the
description of the API and use it as normal you reach this pitfall. I was
looking
for some approach to avoid this as much as possible. For getopt() I see
there's
even no standard getopt_r(), so we would have to provide our own, which
may not
be a bad idea.
Still, this issue will probably present in many other places.

>
> Nathan
>

Best,
Matias

RE: STM32H7 ethernet hardfaults

[David Sidrane]

Hi James,
> Do you guys have any iperf numbers for UDP on H7?

No, I do not. But not that iperf is in apps, it should be easy to get.

David


-Original Message-
From: James Dougherty [mailto:jafr...@gmail.com]
Sent: Friday, March 05, 2021 9:45 AM
To: dev@nuttx.apache.org
Subject: Re: STM32H7 ethernet hardfaults

Wow, nice! Thank you guys!
David, nice description of the descriptors, it looks like zero padding is
being done by the MAC.
Do you guys have any iperf numbers for UDP on H7?



On Fri, Mar 5, 2021 at 7:15 AM John Rippetoe 
wrote:

> Wow, that was fast David! Good find on the cache invalidation issue.
> I'll get your fix running on my board to verify the hard faults have
> been resolved.
>
> Thanks everyone for all of your input and help!
>
> - John
>
> On 3/5/21 9:11 AM, David Sidrane wrote:
> > PR is in. Please have a look and test with the default
> > CONFIG_NET_ETH_PKTSIZE. All should be happy now. :)
> >
> > https://github.com/apache/incubator-nuttx/pull/2985
> >
> > -Original Message-
> > From: David Sidrane [mailto:david.sidr...@nscdg.com]
> > Sent: Friday, March 05, 2021 1:26 AM
> > To: 'dev@nuttx.apache.org'
> > Subject: RE: STM32H7 ethernet hardfaults
> >
> > Hi,
> >
> > Thank you all for sharing your Networking and dcache expertise!
> >
> > The descriptors and buffers are all aligned and sized for the dcache
> > line
> > size.
> >
> > The problem is the following. (The value of number do not matter, but
> help
> > express the nature of the problem.)
> >
> > If CONFIG_NET_ETH_PKTSIZE is the default 490 and a 1518 frame on the
> network
> > is received by the F7.
> >
> > The DMA HW will store the frame as n buffer sizes segments and one or 0
> > remainder sizes buffer.
> >
> > The following will happen:
> >
> > 490 becomes 608 after the sizing and alignment.
> >
> > DMA populates the buffers from the descriptors
> >
> > +>D0->B0(608) the FL is 1518 the d_len is set to 1514. FL from (FL bits
> in
> > RDES0[29:16]) - 4
> > ||
> > |V
> > |D1->B1(608)
> > ||
> > |   V
> > |   D2->B2(298)
> > |   
> > |   |
> > |   V
> > <+Dn->Bn[]
> > 
> >
> >  From RM410: To compute the amount of valid data in this final buffer,
> the
> > driver must read the frame length (FL bits in RDES0[29:16])  and
> > subtract
> > the sum of the buffer sizes of the preceding buffers in this frame.
> >
> > But the code is invalidating from [0] to [1513]. If the buffers
> were
> > contiguous in memory this would be ok. But the buffers that are used in
> RX
> > are replaced (in the descriptors) from the free pool using the
> > g_txbuffer
> > memory.
> >
> > While at boot B0 to Bn are contiguous, they become scattered as a
> process of
> > receiving (the nature of the ring and replacement from the free pool)
> >
> > The ring:
> >
> > /* Scan descriptors owned by the CPU.  Scan until:
> > *
> > *   1) We find a descriptor still owned by the DMA,
> > *   2) We have examined all of the RX descriptors, or
> > *   3) All of the TX descriptors are in flight.
> > *
> >
> > The replacement:
> >
> >buffer = stm32_allocbuffer(priv);
> >/* Take the buffer from the RX descriptor of the first
> free
> > * segment, put it into the network device structure,
> > then
> > * replace the buffer in the RX descriptor with the newly
> > * allocated buffer.
> > */
> >dev->d_buf= (uint8_t *)rxcurr->rdes2;
> >rxcurr->rdes2 = (uint32_t)buffer;
> >
> >
> > Eventually, B0 is allocated from one of the buffers in the g_txbuffer
> array.
> >
> >
> > Given this layout of memory low-high
> >
> >   /* Descriptor allocations */
> >
> >   g_rxtable[RXTABLE_SIZE]
> >   g_txtable[TXTABLE_SIZE]
> >
> >   /* Buffer allocations */
> >
> >   g_rxbuffer[RXBUFFER_ALLOC]
> >   g_txbuffer[TXBUFFER_ALLOC]
> >
> >   /* These are the pre-allocated Ethernet device structures */
> >
> >   stm32_ethmac_s g_stm32ethmac[STM32F7_NETHERNET];
> >
> > The dev->d_buf is an address in g_txbuffer. dev->d_len is the Frame
> Length
> > 1514 NOT the buffer length!
> >
> > The up_invalidate_dcache then corrupts the g_stm32ethmac. The

RE: STM32H7 ethernet hardfaults

[David Sidrane]

PR is in. Please have a look and test with the default
CONFIG_NET_ETH_PKTSIZE. All should be happy now. :)

https://github.com/apache/incubator-nuttx/pull/2985

-Original Message-
From: David Sidrane [mailto:david.sidr...@nscdg.com]
Sent: Friday, March 05, 2021 1:26 AM
To: 'dev@nuttx.apache.org'
Subject: RE: STM32H7 ethernet hardfaults

Hi,

Thank you all for sharing your Networking and dcache expertise!

The descriptors and buffers are all aligned and sized for the dcache line
size.

The problem is the following. (The value of number do not matter, but help
express the nature of the problem.)

If CONFIG_NET_ETH_PKTSIZE is the default 490 and a 1518 frame on the network
is received by the F7.

The DMA HW will store the frame as n buffer sizes segments and one or 0
remainder sizes buffer.

The following will happen:

490 becomes 608 after the sizing and alignment.

DMA populates the buffers from the descriptors

+>D0->B0(608) the FL is 1518 the d_len is set to 1514. FL from (FL bits in
RDES0[29:16]) - 4
||
|V
|D1->B1(608)
||
|   V
|   D2->B2(298)
|   
|   |
|   V
<+Dn->Bn[]


>From RM410: To compute the amount of valid data in this final buffer, the
driver must read the frame length (FL bits in RDES0[29:16])  and subtract
the sum of the buffer sizes of the preceding buffers in this frame.

But the code is invalidating from [0] to [1513]. If the buffers were
contiguous in memory this would be ok. But the buffers that are used in RX
are replaced (in the descriptors) from the free pool using the g_txbuffer
memory.

While at boot B0 to Bn are contiguous, they become scattered as a process of
receiving (the nature of the ring and replacement from the free pool)

The ring:

/* Scan descriptors owned by the CPU.  Scan until:
   *
   *   1) We find a descriptor still owned by the DMA,
   *   2) We have examined all of the RX descriptors, or
   *   3) All of the TX descriptors are in flight.
   *

The replacement:

  buffer = stm32_allocbuffer(priv);
  /* Take the buffer from the RX descriptor of the first free
   * segment, put it into the network device structure, then
   * replace the buffer in the RX descriptor with the newly
   * allocated buffer.
   */
  dev->d_buf= (uint8_t *)rxcurr->rdes2;
  rxcurr->rdes2 = (uint32_t)buffer;


Eventually, B0 is allocated from one of the buffers in the g_txbuffer array.


Given this layout of memory low-high

/* Descriptor allocations */

g_rxtable[RXTABLE_SIZE]
g_txtable[TXTABLE_SIZE]

/* Buffer allocations */

g_rxbuffer[RXBUFFER_ALLOC]
g_txbuffer[TXBUFFER_ALLOC]

/* These are the pre-allocated Ethernet device structures */

stm32_ethmac_s g_stm32ethmac[STM32F7_NETHERNET];

The dev->d_buf is an address in g_txbuffer. dev->d_len is the Frame Length
1514 NOT the buffer length!

The up_invalidate_dcache then corrupts the g_stm32ethmac. The result is
dev->d_buf and + dev->d_len are both 0.

Context before the call to up_invalidate_dcache

dev->d_buf = _txbuffer[n * (RXBUFFER_ALLOC/608)]
dev->d_len = 1514

  up_invalidate_dcache((uintptr_t)dev->d_buf,
   (uintptr_t)dev->d_buf + dev->d_len);

Context after the call to up_invalidate_dcache
dev->d_buf =0
dev->d_len = 0


This then returns OK and stm32_receive dereferences a null pointer and
places the null into the free pool.
The hard fault then happens.

When the CONFIG_NET_ETH_PKTSIZE is 1514, the corruption does to happen
because sizeof FRAME  == sizeof BUFFER

(The system will still crash if the hardware can receive a bigger frame the
numbers are relaitve)

The driver is not quite right, the code manages the segments but does not
coalesce them back in to a frame. (memcpy with such a DMA is gross thought)
So the data RX data is useless to the network layer.

If the network layers used IOB and could deal with on the fly assembly the
system would be most efficient. But that is a major undertaking.

The goal now is to harden the driver.

1) Discard frames (all segments) grater then the size of one buffer.
2) Fix the invalidation.

David


-Original Message-
From: Gregory Nutt [mailto:spudan...@gmail.com]
Sent: Thursday, March 04, 2021 5:01 PM
To: dev@nuttx.apache.org
Subject: Re: STM32H7 ethernet hardfaults


> My question for Greg was: Is there an assumption that
> CONFIG_NET_ETH_PKTSIZE
> has to be 1514? So that ultimately a frame must be received completely
> into
> one buffer?

Search for packet and frame in the Ethernet section of the reference
manual.  The hardware will DMA up to (I think it was) 2048 bytes without
Jumbo mode.  These are the 2K packets.  This is for the H7 (and probably
the F7).

However, that should not happen because nothing should ever s

RE: STM32H7 ethernet hardfaults

[David Sidrane]

Hi,

Thank you all for sharing your Networking and dcache expertise!

The descriptors and buffers are all aligned and sized for the dcache line
size.

The problem is the following. (The value of number do not matter, but help
express the nature of the problem.)

If CONFIG_NET_ETH_PKTSIZE is the default 490 and a 1518 frame on the network
is received by the F7.

The DMA HW will store the frame as n buffer sizes segments and one or 0
remainder sizes buffer.

The following will happen:

490 becomes 608 after the sizing and alignment.

DMA populates the buffers from the descriptors

+>D0->B0(608) the FL is 1518 the d_len is set to 1514. FL from (FL bits in
RDES0[29:16]) - 4
||
|V
|D1->B1(608)
||
|   V
|   D2->B2(298)
|   
|   |
|   V
<+Dn->Bn[]


>From RM410: To compute the amount of valid data in this final buffer, the
driver must read the frame length (FL bits in RDES0[29:16])  and subtract
the sum of the buffer sizes of the preceding buffers in this frame.

But the code is invalidating from [0] to [1513]. If the buffers were
contiguous in memory this would be ok. But the buffers that are used in RX
are replaced (in the descriptors) from the free pool using the g_txbuffer
memory.

While at boot B0 to Bn are contiguous, they become scattered as a process of
receiving (the nature of the ring and replacement from the free pool)

The ring:

/* Scan descriptors owned by the CPU.  Scan until:
   *
   *   1) We find a descriptor still owned by the DMA,
   *   2) We have examined all of the RX descriptors, or
   *   3) All of the TX descriptors are in flight.
   *

The replacement:

  buffer = stm32_allocbuffer(priv);
  /* Take the buffer from the RX descriptor of the first free
   * segment, put it into the network device structure, then
   * replace the buffer in the RX descriptor with the newly
   * allocated buffer.
   */
  dev->d_buf= (uint8_t *)rxcurr->rdes2;
  rxcurr->rdes2 = (uint32_t)buffer;


Eventually, B0 is allocated from one of the buffers in the g_txbuffer array.


Given this layout of memory low-high

/* Descriptor allocations */

g_rxtable[RXTABLE_SIZE]
g_txtable[TXTABLE_SIZE]

/* Buffer allocations */

g_rxbuffer[RXBUFFER_ALLOC]
g_txbuffer[TXBUFFER_ALLOC]

/* These are the pre-allocated Ethernet device structures */

stm32_ethmac_s g_stm32ethmac[STM32F7_NETHERNET];

The dev->d_buf is an address in g_txbuffer. dev->d_len is the Frame Length
1514 NOT the buffer length!

The up_invalidate_dcache then corrupts the g_stm32ethmac. The result is
dev->d_buf and + dev->d_len are both 0.

Context before the call to up_invalidate_dcache

dev->d_buf = _txbuffer[n * (RXBUFFER_ALLOC/608)]
dev->d_len = 1514

  up_invalidate_dcache((uintptr_t)dev->d_buf,
   (uintptr_t)dev->d_buf + dev->d_len);

Context after the call to up_invalidate_dcache
dev->d_buf =0
dev->d_len = 0


This then returns OK and stm32_receive dereferences a null pointer and
places the null into the free pool.
The hard fault then happens.

When the CONFIG_NET_ETH_PKTSIZE is 1514, the corruption does to happen
because sizeof FRAME  == sizeof BUFFER

(The system will still crash if the hardware can receive a bigger frame the
numbers are relaitve)

The driver is not quite right, the code manages the segments but does not
coalesce them back in to a frame. (memcpy with such a DMA is gross thought)
So the data RX data is useless to the network layer.

If the network layers used IOB and could deal with on the fly assembly the
system would be most efficient. But that is a major undertaking.

The goal now is to harden the driver.

1) Discard frames (all segments) grater then the size of one buffer.
2) Fix the invalidation.

David


-Original Message-
From: Gregory Nutt [mailto:spudan...@gmail.com]
Sent: Thursday, March 04, 2021 5:01 PM
To: dev@nuttx.apache.org
Subject: Re: STM32H7 ethernet hardfaults


> My question for Greg was: Is there an assumption that
> CONFIG_NET_ETH_PKTSIZE
> has to be 1514? So that ultimately a frame must be received completely
> into
> one buffer?

Search for packet and frame in the Ethernet section of the reference
manual.  The hardware will DMA up to (I think it was) 2048 bytes without
Jumbo mode.  These are the 2K packets.  This is for the H7 (and probably
the F7).

However, that should not happen because nothing should ever send packets
that large to the station (and PROMISCUOUS mode should be disabled).

 From what you are saying, the packet buffer should also be aligned to
the cache line and be a multiple of the cache line size.  So for an MTU
of X, I think that should be

mask = Y - 1

size = ( (X + 18) + mask) & ~mask

buffer = memalign(Y, size);

where

  * X is the MTU (like 1500).  The MTU does not include the Ethernet

RE: STM32H7 ethernet hardfaults

[David Sidrane]

Hi John,

Jinx you owe me a soda! I am just debugging this same thing today.

This is happening on the F7 as well. It is a bug, in this line.

  up_invalidate_dcache((uintptr_t)dev->d_buf,
   (uintptr_t)dev->d_buf + dev->d_len);


It in performs cache invalidation using the Frame length (1514) from the
descriptor and not the actual length of the buffer (590) moreover the
segment buffers are not necessarily contiguous in memory.

This corrupts g_stm32ethmac. And sets the d_buf and d_len to 0, that cause
that fault downstream.

My question for Greg was: Is there an assumption that CONFIG_NET_ETH_PKTSIZE
has to be 1514? So that ultimately a frame must be received completely into
one buffer?

There is no segmentation reassembly in the code. So I will do a pr to drop
what does not fit  and do the invalidation on min(BUFFSIZE, dev->d_len);

David




-Original Message-
From: John Rippetoe [mailto:jrippe...@roboticresearch.com]
Sent: Thursday, March 04, 2021 12:46 PM
To: dev@nuttx.apache.org
Subject: STM32H7 ethernet hardfaults

Hello All,

I've been playing around with networking on the STM32H7 and am seeing
hardfaults that appear to be related to NET_ETH_PKTSIZE. From the log
below, the driver would appear to be dropping packets that are too large
to fit into the default packet size of 590. By increasing the packet
size to the max (1518), the problem seems to disappear, but I am a
little confused why the driver is able to catch the fact that the
received packet was too large and drop it appropriately, but then crash.
After poking around the ethernet driver, I think I understand the issue
to be that because the MAC DMA does not know that the buffer it is
writing into has a size limit, it is overflowing the buffer and writing
into adjacent memory. Am I understanding this correctly?

My main concern here is that increasing NET_ETH_PKTSIZE to the limit
will only hide the issue for a time instead of solving it. A quick
google search does show that the maximum ethernet frame size is 1518
bytes though, so I am working under the assumption that maxing it out in
my config will account for all possible frame sizes and eliminate this
issue. I have no experience with low level networking protocols and
standards, so I thought it would be prudent to seek out additional help
to make sure I am on the right track.

Thanks in advance.

- John

stm32_receive: WARNING: DROPPED Too big: 684
ipv4_input: WARNING: Not destined for us; not forwardable... Dropping!
ipv4_input: WARNING: Not destined for us; not forwardable... Dropping!
ipv4_input: WARNING: Not destined for us; not forwardable... Dropping!
ipv4_input: WARNING: Not destined for us; not forwardable... Dropping!
ipv4_input: WARNING: Not destined for us; not forwardable... Dropping!
stm32_receive: WARNING: DROPPED Too big: 1332
ipv4_input: WARNING: Not destined for us; not forwardable... Dropping!
ipv4_input: WARNING: Not destined for us; not forwardable... Dropping!
ipv4_input: WARNING: Not destined for us; not forwardable... Dropping!
ipv4_input: WARNING: Not destined for us; not forwardable... Dropping!
stm32_receive: WARNING: DROPPED Too big: 1264
ipv4_input: WARNING: Not destined for us; not forwardable... Dropping!
stm32_receive: WARNING: DROPPED Too big: 684
ipv4_input: WARNING: Not destined for us; not forwardable... Dropping!
ipv4_input: WARNING: Not destined for us; not forwardable... Dropping!
ipv4_input: WARNING: Not destined for us; not forwardable... Dropping!
ipv4_input: WARNING: Not destined for us; not forwardable... Dropping!
ipv4_input: WARNING: Not destined for us; not forwardable... Dropping!
ipv4_input: WARNING: Not destined for us; not forwardable... Dropping!
stm32_receive: WARNING: DROPPED Too big: 1364
ipv4_input: WARNING: Not destined for us; not forwardable... Dropping!
ipv4_input: WARNING: Not destined for us; not forwardable... Dropping!
ipv4_input: WARNING: Not destined for us; not forwardable... Dropping!
ipv4_input: WARNING: Not destined for us; not forwardable... Dropping!
stm32_receive: WARNING: DROPPED Too big: 1264
ipv4_input: WARNING: Not destined for us; not forwardable... Dropping!
ipv4_input: WARNING: Not destined for us; not forwardable... Dropping!
ipv4_input: WARNING: Not destined for us; not forwardable... Dropping!
ipv4_input: WARNING: Not destined for us; not forwardable... Dropping!
ipv4_input: WARNING: Not destined for us; not forwardable... Dropping!
ipv4_input: WARNING: Not destined for us; not forwardable... Dropping!
stm32_receive: WARNING: DROPPED Too big: 1436
ipv4_input: WARNING: Not destined for us; not forwardable... Dropping!
ipv4_input: WARNING: Not destined for us; not forwardable... Dropping!
ipv4_input: WARNING: Not destined for us; not forwardable... Dropping!
ipv4_input: WARNING: Not destined for us; not forwardable... Dropping!
stm32_receive: WARNING: DROPPED Too big: 1300
ipv4_input: WARNING: Not destined for us; not forwardable... Dropping!
ipv4_input: 

RE: CONFIG_NSH_CMDPARMS not working as expected

[David Sidrane]

Do you have a writeable /tmp? It would have to be /fs/microsd/tmp

"interim output will be retained in a temporary file. Full path to a
directory where temporary files can be created is taken from
CONFIG_LIBC_TMPDIR and it defaults to /tmp if CONFIG_LIBC_TMPDIR is not
set."

David

-Original Message-
From: Pieter-Jan Dewitte [mailto:pieterjan.dewi...@atmosuav.com]
Sent: Tuesday, February 16, 2021 4:09 AM
To: dev@nuttx.apache.org
Subject: CONFIG_NSH_CMDPARMS not working as expected

Hi all,

I'm looking for help and found on Github this is the best way.

In short, I don't understand why "set FOO `pwd`" gives me this error:

"nsh: pwd: open failed: No such file or directory"


I don't understand it because the documentation
suggests
this should work if  CONFIG_NSH_CMDPARMS is enabled.

Context:

   - I'm using Nuttx through PX4 with the "Cube Orange"
   - In the configuration of that board I see "CONFIG_NSH_CMDPARMS" turned
   on:
  -
  
https://github.com/PX4/PX4-Autopilot/blob/master/boards/cubepilot/cubeorange/nuttx-config/console/defconfig
  -
  
https://github.com/PX4/PX4-Autopilot/blob/master/boards/cubepilot/cubeorange/nuttx-config/nsh/defconfig
  - I'm afraid that as an end user, I don't know what the
  difference between these configurations is and how I can tell whether
the
  parameter is in fact enabled in the shell I'm accessing

For reference, I asked this question earlier also on the PX4 forum:
https://discuss.px4.io/t/nuttx-output-from-commands/21015


Any help or pointers are appreciated!


Best regards / Vriendelijke groet,

Pieter-Jan Dewitte
R Engineer
*ATMOS UAV B.V.*
Hangaargebied
Marinevliegkamp 356
2236ZZ Valkenburg ZH
The Netherlands

+31 (0) 15 744 0321
pieterjan.dewi...@atmosuav.com
www.atmosuav.com

RE: Proper handling of arch header files

[David Sidrane]

Those are sources of generic information passed to the drivers. Not
intrinsic data of the SoC (like its memory map).

-Original Message-
From: Grr [mailto:gebbe...@gmail.com]
Sent: Saturday, February 06, 2021 7:12 AM
To: dev@nuttx.apache.org
Subject: Re: Proper handling of arch header files

> It is very non-modular if it exposes internal data.  Tha must be
> strictly avoided and prohibited in all cases.
>

So you mean exposing STM32_BOARD_XTAL and STM32_SYSCLK_FREQUENCY is OK but
exposing board IO port address violates modularity

That logic escapes me

RE: Task with statically allocated stack

[David Sidrane]

You have to init the memory used for the stack:

Have a look in the normal tasking init , and you will see the call out to
init the stack, that you neeed to call.

Also Assuming ARM it has to be 8 byte aligned. So you need attributes on
your variable called stack to set the alignment.

David
-Original Message-
From: Fotis Panagiotopoulos [mailto:f.j.pa...@gmail.com]
Sent: Saturday, February 06, 2021 6:08 AM
To: dev@nuttx.apache.org
Subject: Task with statically allocated stack

Hi,

I am trying to create a new task using a statically allocated stack.

Here is my code:

static struct task_tcb_s tcb;
static uint8_t stack[CONFIG_NETWORK_THREAD_STACKSIZE]

void start_my_thread()
{
 memset(, 0, sizeof(struct task_tcb_s));
 tcb.cmn.flags = TCB_FLAG_TTYPE_TASK;

 int ret = nxtask_init(, "Network", CONFIG_NETWORK_THREAD_PRIORITY,
stack, CONFIG_NETWORK_THREAD_STACKSIZE, network_th, NULL);
 if (ret < 0)
 {
  //error handling...
 }

 nxtask_activate();
}


This new thread seems to be working OK (I haven't done any extensive
testing yet), but running ps in nsh yields:

5  80 FIFO Task--- Ready   008156 008156
100.0%! Network

The stack is always reported as 100% full. I tried increasing it to
excessive numbers but it still.
I believe that I have configured something wrong? Or this is not the
correct way to init a task with a static stack?

RE: Anyone else getting repeated emails from the GitBox?

[David Sidrane]

I totally agree, I was always concerned that commits to the Apache directly
would get missed. So I had it on.


I could not even unsubscribe

Hi! This is the ezmlm program. I'm managing the comm...@nuttx.apache.org
mailing list.

Acknowledgment: The address

   david.sidr...@nscdg.com

was not on the commits mailing list when I received your request and is not
a subscriber of this list.

- the tools suck!

-Original Message-
From: Matias N. [mailto:mat...@imap.cc]
Sent: Friday, February 05, 2021 5:27 AM
To: dev@nuttx.apache.org
Subject: Re: Anyone else getting repeated emails from the GitBox?

I actually delete gitbox messages on arrival. I find GitHub notifications
much more usable.

Best,
Matias

RE: Anyone else getting repeated emails from the GitBox?

[David Sidrane]

Are you getting duplicate same email a day later?

-Original Message-
From: Abdelatif Guettouche [mailto:abdelatif.guettou...@gmail.com]
Sent: Friday, February 05, 2021 2:47 AM
To: dev@nuttx.apache.org
Subject: Re: Anyone else getting repeated emails from the GitBox?

All of Gitbox emails are now going to commits@ which you can filter
out or simply unsubscribe.

On Fri, Feb 5, 2021 at 11:40 AM David Sidrane 
wrote:
>
> Anyone else getting repeated emails from the GitBox?
>
>
>
> -Original Message-
> From: GitBox [mailto:g...@apache.org]
> Sent: Friday, February 05, 2021 2:29 AM
> To: comm...@nuttx.apache.org
> Subject: [GitHub] [incubator-nuttx] xiaoxiang781216 merged pull request
> #2805: imxrt1060 iperf
>
>
> xiaoxiang781216 merged pull request #2805:
> URL: https://github.com/apache/incubator-nuttx/pull/2805
>
>
>
>
>
> 
> This is an automated message from the Apache Git Service.
> To respond to the message, please log on to GitHub and use the
> URL above to go to the specific comment.
>
> For queries about this service, please contact Infrastructure at:
> us...@infra.apache.org

Anyone else getting repeated emails from the GitBox?

[David Sidrane]

Anyone else getting repeated emails from the GitBox?



-Original Message-
From: GitBox [mailto:g...@apache.org]
Sent: Friday, February 05, 2021 2:29 AM
To: comm...@nuttx.apache.org
Subject: [GitHub] [incubator-nuttx] xiaoxiang781216 merged pull request
#2805: imxrt1060 iperf


xiaoxiang781216 merged pull request #2805:
URL: https://github.com/apache/incubator-nuttx/pull/2805






This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org

RE: I saw a new option for merging in GH: Auto merge when CI completes

[David Sidrane]

Yes.

But that feature needs to be enabled for us by infra.

-Original Message-
From: Abdelatif Guettouche [mailto:abdelatif.guettou...@gmail.com]
Sent: Friday, February 05, 2021 2:04 AM
To: dev@nuttx.apache.org
Subject: Re: I saw a new option for merging in GH: Auto merge when CI
completes

We set it manually right?
I mean after reviewing we can set the PR to be merged when the CI
checks are done?

On Fri, Feb 5, 2021 at 10:53 AM David Sidrane 
wrote:
>
> Hi,
>
> I saw a new option for merging in GH Auto merge when CI completes.
>
> What is the group's opinion on having this enabled?
>
> David

I saw a new option for merging in GH: Auto merge when CI completes

[David Sidrane]

Hi,

I saw a new option for merging in GH Auto merge when CI completes.

What is the group's opinion on having this enabled?

David

RE: Automatically setup correct Eth PHY bitmasks?

[David Sidrane]

My recollection is there is the standard interface common to all PHY (first
16 regs). The only setting needed is the base address.

Only once CONFIG_STM32H7_AUTONEG is enabled, one of the other 2 sets are
needed chosen by CONFIG_STM32H7_PHYSR_ALTCONFIG.

The issue you face is the mapping. You could have CONFIG_PHYREG_
published by the phy Kconfig choice selection.
You still will need the BASE address(s) (more than one may be needed)

Then one could use the CONFIG_PHYREG_ values in all the archs.

For this to be usable all PHY and all arch's will need to be reworked.

David


-Original Message-
From: Nathan Hartman [mailto:hartman.nat...@gmail.com]
Sent: Sunday, January 03, 2021 3:35 PM
To: dev@nuttx.apache.org
Subject: Automatically setup correct Eth PHY bitmasks?

I made a custom board using STM32H7 with KSZ8081 Ethernet PHY.

Then I noticed it is necessary to setup CONFIG_STM32H7_PHYSR,
CONFIG_STM32H7_PHYSR_ALTCONFIG, CONFIG_STM32H7_PHYSR_ALTMODE,
CONFIG_STM32H7_PHYSR_10HD, CONFIG_STM32H7_PHYSR_100HD,
CONFIG_STM32H7_PHYSR_10FD, and CONFIG_STM32H7_PHYSR_100FD in Kconfig, i.e.,
manually input the address within the PHY of a particular register and
bitmasks to
use with that register.

Isn't this information invariant to the Ethernet PHY? That is, all KSZ8081
will always have this register at 0x1e and always use the same bitmasks to
access the same data?

If so, this could be programmed in Kconfig and automatically set when
choosing this PHY?

Did I misunderstand / am I missing anything?

Thanks,
Nathan

RE: about IDEs and dev boards

[David Sidrane]

Hi Brennen,

I have not tested with vscode in a bit. But the issue for me before was the
edit ability of registers on IP blocks and CPU. Ben may be referring to the
hard fault debugging technique I presented at the NuttX conference 2 years
ago. It is a simple cut and paste from the LR to the IP regs in the eclipse
GUI, and IIRC a ton of typing in VS code or read only. Has that improved?

David

-Original Message-
From: Brennan Ashton [mailto:bash...@brennanashton.com]
Sent: Wednesday, December 09, 2020 5:59 PM
To: dev@nuttx.apache.org
Subject: Re: about IDEs and dev boards

Marlar
With the plugin that I linked you should be able to nice debugging without
having to use two different environments. Just don't use the native vscode
debugger from the c++ it has long standing issues with remote targets.

Ben is there a reason you don't use it for hardfaults? I'm not sure I quite
understand what you would run into with that.

--Brennan

On Wed, Dec 9, 2020, 5:30 PM Marlar Chan  wrote:

> Dear Ben,
>Is there any setup guideline for Nuttx debuggig with VSCode (normal
> use) and Eclipse (Hard faults)?
>
> Best Regards,
> Marlar
> 
> From: Disruptive Solutions 
> Sent: Wednesday, December 9, 2020 6:16 PM
> To: dev@nuttx.apache.org 
> Subject: Re: about IDEs and dev boards
>
> VSCode (normal use) and Eclipse (Hard faults).
>
> STM32 stack (nucleos, blackboards, etc) and own reference board(s).
>
> Hardware as extra tools (logic analyzer, scope, seggers, st link, etc)
>
> And just having fun to use NuttX and the results one can achieve.
> Still
> mind blowing!!!
>
> Ben
>
> Op wo 9 dec. 2020 8:39 a.m. schreef Marc Rosen :
>
> >
> > Am 04.12.2020 um 02:54 schrieb Matias N.:
> > > Hi,
> > > I was wondering what IDEs do you use with NuttX and what is your
> > preferred dev board (can be more than one).
> > > I'm curious since I have used QtCreator for long time now and
> > > generally
> > works well, but it has some quirks.
> > Jetbrains CLion is the IDE i use. It is not that great with Makefile
> > projects and debugging but it is getting better.
> > And it works well if you also use some of their other dev tools and
> > ides.
> > > And on hardware side I always favored STM32 boards (with embedded
> > debugger) but after getting into nRF52 I found
> > > it to be much easier to work with and seems a very well designed SoC
> > from the users perspective. The "mux (almost) any peripheral to any pin"
> is
> > great (any other chip does that?).
> > >
> > > Best,
> > > Matias
> > Mostly AVRs here, the ones too small for Nuttx, and STM32. Usually
> > custom boards.
> >
> > regards,
> > Marc
> >
> >
> 
>
> CONFIDENTIALITY: This email is intended solely for the person(s) named and
> may be confidential and/or privileged. If you are not the intended
> recipient, please delete it, notify us and do not copy, use, or disclose
> its contents.
> Towards a sustainable earth: Print only when necessary. Thank you.
>

RE: about IDEs and dev boards

[David Sidrane]

Hi Matais,

I use GNU ARM Eclipse http://gnuarmeclipse.github.io/ but it is now
https://eclipse-embed-cdt.github.io/

I value it for the Segger debugger integration and SVD support.

I use make file builds imported from git.

I use a lot of the PX4 boards the FMUv2 2.4.6 (Pixhawk2), FMUv4 (Pixracer
RC15) FMUV5 (Pixhawk4)

IMXRT10x0-EVK
Nuceo-144 (F7,H7...)
OlimexSTM32

I always disable the built-in JTAG and use a Segger JLink or a JTrace and
real FTDI serial ports (isolated), not virtual ones. This decouples the
debugging hHW from the power cycling of the target.

Imxrt has a cross bar switch but it is not any-to-any as it sounds like
the nRF52 is.

David

-Original Message-
From: Matias N. [mailto:mat...@imap.cc]
Sent: Thursday, December 03, 2020 5:54 PM
To: dev@nuttx.apache.org
Subject: about IDEs and dev boards

Hi,
I was wondering what IDEs do you use with NuttX and what is your preferred
dev board (can be more than one).
I'm curious since I have used QtCreator for long time now and generally
works well, but it has some quirks.
And on hardware side I always favored STM32 boards (with embedded
debugger) but after getting into nRF52 I found
it to be much easier to work with and seems a very well designed SoC from
the users perspective. The "mux (almost) any peripheral to any pin" is
great (any other chip does that?).

Best,
Matias

RE: STM32F4 SPI DMA buffer size issue

[David Sidrane]

Oleg,

You are most welcome,

Did you adjust the size of the board dma allocator?

https://github.com/PX4/PX4-Autopilot/blob/1dd6b6a5058199ea6bbf1e2321010abe88a656ee/platforms/nuttx/src/px4/common/board_dma_alloc.c#L57?

-Original Message-
From: Oleg Evseev [mailto:ev.m...@gmail.com]
Sent: Wednesday, November 25, 2020 12:46 AM
To: dev@nuttx.apache.org
Subject: Re: STM32F4 SPI DMA buffer size issue

Thanks for the enhanced feedback, David!

When I reduced the slew rate control from 50MHz to 2MHz it fixes issues
with a SD card when DMA is not enabled. But when DMA is enabled, MTD and SD
still are attached and mounted, but are empty, as I see on block reads -
px4 successfully reads mtd_params files, but it is empty. SD content also
empty, ls shows only created empty log dir on boot, but can't store
anything (for example on echo - "No such file or directory").
I turned off all uart DMA just in case, but it didn't help.

вт, 24 нояб. 2020 г. в 21:45, David Sidrane :

> Hi Oleg,
>
> See inline [DBS]
>
> David
> -Original Message-
> From: Oleg Evseev [mailto:ev.m...@gmail.com]
> Sent: Tuesday, November 24, 2020 9:46 AM
> To: dev@nuttx.apache.org
> Subject: Re: STM32F4 SPI DMA buffer size issue
>
> > Have you scoped the interface?
>
> You mean a bus by analyzer? No, I don't have such ability for now.
>
> [DBS]  Use an oscilloscope, but with a high speed FET probe. You may see
> incredible overshoot, when DMA is on.
>
>
> For SD card I tried to reduce the SPI frequency from 24MHz to 10MHz, but
> it
> didn't help when DMA is enabled. In fact it get failed to find a valid
> boot
> record, while fat_hwread of sector zero is returned without errors.
>
>
> [DBS] By drive strength I mean the slew rate control not frequency
>
> See
>
> https://github.com/PX4/PX4-Autopilot/blob/master/boards/px4/fmu-v6x/nuttx-config/include/board.h#L411-L431
> For an eample.
>
> The other strange thing I found out, is that when *DMA is not used*, SD
> can't be used after mounting on boot. If I go through breakpoints in stm32
> spi_setfrequency for example it get mounted ok and ls shows SD content.
> It's hard to understand what is going on because it seems that debug
> influence on the result. While debugging I saw the case when SD get
> mounted
> but than on mkdir of log folder reading mmcsd_geometry get failed in
> mmcsd_getcsd or mkdir success, but log dir is the only one thing on SD
> while it is not empty.
>
> In this case (without DMA) reducing SPI frequency from 24MHz to 20MHz
> seems
> to fix the problem (but maybe it depends on delays and may appear again
> once there will be more commands on boot for instance, I don't know).
>
> Quite a strange behaviour for now.
>
> вт, 24 нояб. 2020 г. в 17:12, David Sidrane :
>
> > Oleg,
> >
> > Have you scoped the interface?
> >
> > For gins and giggles try reducing the SPI clock drive strength. Step it
> > down
> > and retest.
> >
> > David
> >
> > -Original Message-
> > From: Oleg Evseev [mailto:ev.m...@gmail.com]
> > Sent: Tuesday, November 24, 2020 4:57 AM
> > To: dev@nuttx.apache.org
> > Subject: STM32F4 SPI DMA buffer size issue
> >
> > Hi all,
> >
> > STM32f405rg custom board - MTD on SPI1 and SD card on SPI2.
> >
> > MTD on SPI1 works without DMA and with if defined
> > CONFIG_STM32_SPI1_DMA=y
> >
> > but if also
> > CONFIG_STM32_SPI1_DMA_BUFFER=1024
> > is set, partitions get created, there are mtdblockX in /dev, geometry
> > can
> > be read correctly, but reading or writing hangs up.
> > As I see in map g_spi1_rxbuf, g_spi1_txbuf are in SRAM, not in CCM.
> >
> > Same with SD card. If defined CONFIG_STM32_SPI2_DMA_BUFFER=1024 there is
> > still /dev/mmcsd device, it gets mounted, but ls /fs/microsd shows no SD
> > content.
> >
> > CONFIG_STM32_SPI_DMATHRESHOLD=8
> >
> > What can be a problem? Thanks in advance for help!
> >
> > ---
> > With regards, Oleg.
> >
>

RE: STM32F4 SPI DMA buffer size issue

[David Sidrane]

Hi Oleg,

See inline [DBS]

David
-Original Message-
From: Oleg Evseev [mailto:ev.m...@gmail.com]
Sent: Tuesday, November 24, 2020 9:46 AM
To: dev@nuttx.apache.org
Subject: Re: STM32F4 SPI DMA buffer size issue

> Have you scoped the interface?

You mean a bus by analyzer? No, I don't have such ability for now.

[DBS]  Use an oscilloscope, but with a high speed FET probe. You may see
incredible overshoot, when DMA is on.


For SD card I tried to reduce the SPI frequency from 24MHz to 10MHz, but it
didn't help when DMA is enabled. In fact it get failed to find a valid boot
record, while fat_hwread of sector zero is returned without errors.


[DBS] By drive strength I mean the slew rate control not frequency

See
https://github.com/PX4/PX4-Autopilot/blob/master/boards/px4/fmu-v6x/nuttx-config/include/board.h#L411-L431
For an eample.

The other strange thing I found out, is that when *DMA is not used*, SD
can't be used after mounting on boot. If I go through breakpoints in stm32
spi_setfrequency for example it get mounted ok and ls shows SD content.
It's hard to understand what is going on because it seems that debug
influence on the result. While debugging I saw the case when SD get mounted
but than on mkdir of log folder reading mmcsd_geometry get failed in
mmcsd_getcsd or mkdir success, but log dir is the only one thing on SD
while it is not empty.

In this case (without DMA) reducing SPI frequency from 24MHz to 20MHz seems
to fix the problem (but maybe it depends on delays and may appear again
once there will be more commands on boot for instance, I don't know).

Quite a strange behaviour for now.

вт, 24 нояб. 2020 г. в 17:12, David Sidrane :

> Oleg,
>
> Have you scoped the interface?
>
> For gins and giggles try reducing the SPI clock drive strength. Step it
> down
> and retest.
>
> David
>
> -Original Message-
> From: Oleg Evseev [mailto:ev.m...@gmail.com]
> Sent: Tuesday, November 24, 2020 4:57 AM
> To: dev@nuttx.apache.org
> Subject: STM32F4 SPI DMA buffer size issue
>
> Hi all,
>
> STM32f405rg custom board - MTD on SPI1 and SD card on SPI2.
>
> MTD on SPI1 works without DMA and with if defined CONFIG_STM32_SPI1_DMA=y
>
> but if also
> CONFIG_STM32_SPI1_DMA_BUFFER=1024
> is set, partitions get created, there are mtdblockX in /dev, geometry can
> be read correctly, but reading or writing hangs up.
> As I see in map g_spi1_rxbuf, g_spi1_txbuf are in SRAM, not in CCM.
>
> Same with SD card. If defined CONFIG_STM32_SPI2_DMA_BUFFER=1024 there is
> still /dev/mmcsd device, it gets mounted, but ls /fs/microsd shows no SD
> content.
>
> CONFIG_STM32_SPI_DMATHRESHOLD=8
>
> What can be a problem? Thanks in advance for help!
>
> ---
> With regards, Oleg.
>

RE: STM32F4 SPI DMA buffer size issue

[David Sidrane]

Oleg,

Have you scoped the interface?

For gins and giggles try reducing the SPI clock drive strength. Step it down
and retest.

David

-Original Message-
From: Oleg Evseev [mailto:ev.m...@gmail.com]
Sent: Tuesday, November 24, 2020 4:57 AM
To: dev@nuttx.apache.org
Subject: STM32F4 SPI DMA buffer size issue

Hi all,

STM32f405rg custom board - MTD on SPI1 and SD card on SPI2.

MTD on SPI1 works without DMA and with if defined CONFIG_STM32_SPI1_DMA=y

but if also
CONFIG_STM32_SPI1_DMA_BUFFER=1024
is set, partitions get created, there are mtdblockX in /dev, geometry can
be read correctly, but reading or writing hangs up.
As I see in map g_spi1_rxbuf, g_spi1_txbuf are in SRAM, not in CCM.

Same with SD card. If defined CONFIG_STM32_SPI2_DMA_BUFFER=1024 there is
still /dev/mmcsd device, it gets mounted, but ls /fs/microsd shows no SD
content.

CONFIG_STM32_SPI_DMATHRESHOLD=8

What can be a problem? Thanks in advance for help!

---
With regards, Oleg.

RE: Re[2]: iMXRT1064-EVK nshocram linking issue

[David Sidrane]

Hi Vadim,

Add an entry in section .flashxip or .text for the  _udivmoddi4.o and move
it to see if you can clear the error.

See
https://github.com/PX4/PX4-Autopilot/blob/master/boards/nxp/fmurt1062-v1/nuttx-config/scripts/ocram-script.ld#L105-L137
For what it takes to position an obj module.

David

-Original Message-
From: Вадим Ястребов [mailto:woody_haw...@mail.ru.INVALID]
Sent: Monday, November 23, 2020 11:33 AM
To: dev@nuttx.apache.org
Subject: Re[2]: iMXRT1064-EVK nshocram linking issue


Thank you for your prompt reply, David!

I already have nsh config working from 4MB internal flash which starts from
0x7000. I am not using neither Hyperflash nor external flash. This has
also been verified by measuring voltage values on CE low pins of each chip.
Someone else was also successful in making it work from internal flash as
described on github:
https://github.com/apache/incubator-nuttx/issues/1494

The problem is making it work for nshocram configuration. I cannot seem to
understand what that linking error means.

Thank you.

Vadim

>Понедельник, 23 ноября 2020, 19:09 +03:00 от David Sidrane
>:
>
>Hi Vadim,
>
>I do not recall all the deltas from the 1062 to the 1064. But the 1064 may
>have other IP changes, and memory map differences
>
>You should create a board new directory imxrt1060-evk. And make the changes
>there.
>
>You will need to know what kind of memory is embedded. Hyper flash or QSPI
>
>Also start with nsh config as nshocram is more complex.
>
>David
>
>
>-Original Message-
>From: Вадим Ястребов [mailto:woody_haw...@mail.ru.INVALID]
>Sent: Monday, November 23, 2020 7:56 AM
>To:  dev@nuttx.apache.org
>Subject: iMXRT1064-EVK nshocram linking issue
>
>
>Hello,
>
>My name is Vadim. I am new to NuttX and to the embedded world in general. I
>am trying to compile NuttX nshocram configuration for IMXRT1064-EVK board
>using 1060 configuration with changes to flash-ocram.ld and
>imxrt_flexspi_nor_boot.h.
>
>In imxrt_flexspi_nor_boot.h, I changed FLASH_BASE from 0x6000 to
>0x7000 .
>
>In flash-ocram.ld, I changed:
>flash (rx) : ORIGIN and LENGTH from 0x6000 and 7M to 0x7000
>and 3M → changing origin address alone leads to this error. Everything
>links
>with no issue otherwise (even with other changes excluding this one).
>flashxip (rx) : ORIGIN and LENGTH from 0x6070 and 1M to 0x7030
>and 1M
>
>
>I am getting relocation truncated to fit error:
>
>make[2]: Entering directory
>'/home/vadim/Downloads/nuttx_nov20/nuttx/boards/arm/imxrt/imxrt1060-evk/src'
>CC: imxrt_boot.c
>CC: imxrt_flexspi_nor_boot.c
>CC: imxrt_flexspi_nor_flash.c
>CC: imxrt_appinit.c
>CC: imxrt_bringup.c
>CC: imxrt_autoleds.c
>AR (create): libboard.a imxrt_boot.o imxrt_flexspi_nor_boot.o
>imxrt_flexspi_nor_flash.o imxrt_appinit.o imxrt_bringup.o imxrt_autoleds.o
>make[2]: Leaving directory
>'/home/vadim/Downloads/nuttx_nov20/nuttx/boards/arm/imxrt/imxrt1060-evk/src'
>LD: nuttx
>/usr/lib/gcc/arm-none-eabi/10.2.0/thumb/v7e-m+dp/hard/libgcc.a(_udivmoddi4.o):(.ARM.exidx.text.__udivmoddi4+0x0):
>relocation truncated to fit : R_ARM_PREL31 against `.text.__udivmoddi4'
>make[1]: *** [Makefile:172: nuttx] Error 1
>make[1]: Leaving directory
>'/home/vadim/Downloads/nuttx_nov20/nuttx/arch/arm/src'
>make: *** [tools/Makefile.unix:423: nuttx] Error 2
>
>
>
>I was wondering what needs to be done to make it work?
>
>Please, let me know.
>
>Thank you for your time.
>
>Regards,
>Vadim

RE: iMXRT1064-EVK nshocram linking issue

[David Sidrane]

Hi Vadim,

I do not recall all the deltas from the 1062 to the 1064. But the 1064 may
have other IP changes, and memory map differences

You should create a board new directory imxrt1060-evk. And make the changes
there.

You will need to know what kind of memory is embedded. Hyper flash or QSPI

Also start with nsh config as nshocram is more complex.

David


-Original Message-
From: Вадим Ястребов [mailto:woody_haw...@mail.ru.INVALID]
Sent: Monday, November 23, 2020 7:56 AM
To: dev@nuttx.apache.org
Subject: iMXRT1064-EVK nshocram linking issue


Hello,

My name is Vadim. I am new to NuttX and to the embedded world in general. I
am trying to compile NuttX nshocram configuration for IMXRT1064-EVK board
using 1060 configuration with changes to flash-ocram.ld and
imxrt_flexspi_nor_boot.h.

In imxrt_flexspi_nor_boot.h, I changed  FLASH_BASE from  0x6000 to
0x7000 .

In flash-ocram.ld, I changed:
flash (rx)  : ORIGIN   and  LENGTH from  0x6000 and 7M to  0x7000
and 3M → changing origin address alone leads to this error. Everything links
with no issue otherwise (even with other changes excluding this one).
flashxip (rx)  : ORIGIN and  LENGTH from  0x6070 and 1M to  0x7030
and 1M


I am getting relocation truncated to fit error:

make[2]: Entering directory
'/home/vadim/Downloads/nuttx_nov20/nuttx/boards/arm/imxrt/imxrt1060-evk/src'
CC:  imxrt_boot.c
CC:  imxrt_flexspi_nor_boot.c
CC:  imxrt_flexspi_nor_flash.c
CC:  imxrt_appinit.c
CC:  imxrt_bringup.c
CC:  imxrt_autoleds.c
AR (create): libboard.a   imxrt_boot.o imxrt_flexspi_nor_boot.o
imxrt_flexspi_nor_flash.o imxrt_appinit.o imxrt_bringup.o imxrt_autoleds.o
make[2]: Leaving directory
'/home/vadim/Downloads/nuttx_nov20/nuttx/boards/arm/imxrt/imxrt1060-evk/src'
LD: nuttx
/usr/lib/gcc/arm-none-eabi/10.2.0/thumb/v7e-m+dp/hard/libgcc.a(_udivmoddi4.o):(.ARM.exidx.text.__udivmoddi4+0x0):
relocation truncated to fit : R_ARM_PREL31 against `.text.__udivmoddi4'
make[1]: *** [Makefile:172: nuttx] Error 1
make[1]: Leaving directory
'/home/vadim/Downloads/nuttx_nov20/nuttx/arch/arm/src'
make: *** [tools/Makefile.unix:423: nuttx] Error 2



I was wondering what needs to be done to make it work?

Please, let me know.

Thank you for your time.

Regards,
Vadim

RE: Should TASK_NAME_SIZE be changed in most configs?

[David Sidrane]

Perfect! Let's do this as time permits.

-Original Message-
From: Alan Carvalho de Assis [mailto:acas...@gmail.com]
Sent: Monday, November 23, 2020 5:09 AM
To: dev@nuttx.apache.org
Subject: Re: Should TASK_NAME_SIZE be changed in most configs?

Yes, I think nsh-debug will make its intention clear.

On 11/23/20, Gregory Nutt  wrote:
> It has always been the policy to disable debug features in all shipped
> configurations.  They were considered production configurations not
> debug configurations.
>
> Configurations that have debug enable could, perhaps, be named like
> nsh-debug.
>
> On 11/23/2020 5:38 AM, Alan Carvalho de Assis wrote:
>> I think we need to have a good compromise between features and size.
>>
>> For instance, the default "nsh" demo should be small, basically just
>> the terminal and minimum support to its commands to work, like the
>> PROCFS to get 'free' working.
>>
>> Also keep in mind that for debugging purpose we need to "Suppress
>> Optimization" that also will increase its size.
>>
>> So, I think it could be a good idea to have a predefined config for
>> debug purpose, instead forcing the "nsh" to be debugging enabled ready
>> by default, that will increase its size and send a wrong message for
>> people testing NuttX for the very first time.
>>
>> See the mbedOS for example:
>>
>> https://os.mbed.com/blog/entry/Optimizing-memory-usage-in-mbed-OS-52/
>>
>> They went into 'rabbit's hole' to solve an issue that we don't have
>> yet, but if nobody keep an eye on it soon we will have.
>>
>> BR,
>>
>> Alan
>>
>> On 11/23/20, David Sidrane  wrote:
>>>> Do you think this is due to the
>>> I would say so.
>>>
>>> I agree better debugging out of the box is a good way to go. We have to
>>> weigh that against the past goal of: Minimum size image. It was a first
>>> impression thing. This was why debug had to be tuned off in all Kconfig.
>>>
>>> The first question to ask is do we as a group feel still that the size
>>> of
>>> the canned config built images should be as small as possible to
>>> showcase
>>> NuttX ability to be small?
>>>
>>>
>>> David
>>>
>>>
>>> -Original Message-
>>> From: Matias N. [mailto:mat...@imap.cc]
>>> Sent: Sunday, November 22, 2020 5:18 PM
>>> To: dev@nuttx.apache.org
>>> Subject: Should TASK_NAME_SIZE be changed in most configs?
>>>
>>> While trying the integration of openocd with NuttX it was complaining
>>> due
>>> to "name" not being defined, which happens when CONFIG_TASK_NAME_SIZE ==
>>> 0. Looking at sched/Kconfig the default for this symbol is 31, yet many
>>> configs have this set to zero. Do you think this is due to the default
>>> having changed at some point or is this done to minimize memory use in
>>> all
>>> these boards? If the latter, maybe we need to make the default depend on
>>> CONFIG_DEFAULT_SMALL and update all configs that do not have this set.
>>>
>>> Best,
>>> Matias
>>>
>

RE: Should TASK_NAME_SIZE be changed in most configs?

[David Sidrane]

> Do you think this is due to the

I would say so.

I agree better debugging out of the box is a good way to go. We have to
weigh that against the past goal of: Minimum size image. It was a first
impression thing. This was why debug had to be tuned off in all Kconfig.

The first question to ask is do we as a group feel still that the size of
the canned config built images should be as small as possible to showcase
NuttX ability to be small?


David


-Original Message-
From: Matias N. [mailto:mat...@imap.cc]
Sent: Sunday, November 22, 2020 5:18 PM
To: dev@nuttx.apache.org
Subject: Should TASK_NAME_SIZE be changed in most configs?

While trying the integration of openocd with NuttX it was complaining due
to "name" not being defined, which happens when CONFIG_TASK_NAME_SIZE ==
0. Looking at sched/Kconfig the default for this symbol is 31, yet many
configs have this set to zero. Do you think this is due to the default
having changed at some point or is this done to minimize memory use in all
these boards? If the latter, maybe we need to make the default depend on
CONFIG_DEFAULT_SMALL and update all configs that do not have this set.

Best,
Matias

Please add a subject to the PR titles

[David Sidrane]

To help filter the emails

Please add a subject to the PR titles

Fix compile break   ---> readline:Fix compile break

RE: Serial console strange behaviour

[David Sidrane]

Are you running any PX4IO drivers or RC  input?

-Original Message-
From: Oleg Evseev [mailto:ev.m...@gmail.com]
Sent: Wednesday, November 11, 2020 3:09 AM
To: dev@nuttx.apache.org
Subject: Serial console strange behaviour

Hi,

Custom board stm32f7, PX4 based project - moved from NuttX 8.2 to 10.0.0.
If serial dev console (CONFIG_USART6_SERIAL_CONSOLE=y) is used, it works:
prints all corresponding output on boot, but then

"nsh> " is shown only when I start typing in putty.
"ls" command shows only the first output line. Other lines are shown only
if I type at least one symbol.
I tried with and without CONFIG_USART6_RXDMA - same result.

USB CDC ACM console works OK.

Any thoughts on what can cause such behavior?

---
With best regards, Oleg

RE: interrupt priorities on nRF52

[David Sidrane]

> But the priority difference doesn't imply that the nested interrupt
> happens
automatically, you have to enable the interrupt manually after the critical
CPU register and OS state is saved.

My recollection is it depends on the priority assigned to the interrupt and
the fence level used (NVIC_SYSH_DISABLE_PRIORITY) on the disable. The system
will crash due to reentrancy on the common vector, if the values, and vector
are not managed properly.


-Original Message-
From: Xiang Xiao [mailto:xiaoxiang781...@gmail.com]
Sent: Sunday, October 25, 2020 11:27 PM
To: dev@nuttx.apache.org
Subject: Re: interrupt priorities on nRF52

On Mon, Oct 26, 2020 at 4:52 AM Matias N.  wrote:

> Hi,
> while working on nRF52 BLE link-layer I experienced some problems due to
> delayed ISRs. This can be quite problematic
> for handling all the tight timings required by the standard. I eventually
> reached an implementation that can deal with this relatively well (BLE
> standard gives some leeway for some small number of dropped packets and
> also retransmits missing ones). However, as other peripherals start
> generating more interrupts, this could actually become a problem. Also, I
> think it would be good to know BLE ISRs will always have priority.
>
> I've been looking into how ISRs can be prioritized but I don't have much
> experience with this, so I have some questions:
> * Does nRF52 need explicit support for handling interrupts with different
> priorities or is the support supposed to be taken care of at the ARM level
> code?
> * How well supported is this in nRF52/ARM?
>

You can call up_prioritize_irq(at least Cortex-M implement it) to change
the ISR priority.


> * Do interrupt priorities imply nested interrupts? It isn't clear to me if
> priorities only mean which ISR will get served first when they are pending
> together or if it also implies that a low priority


But the priority difference doesn't imply that the nested interrupt happens
automatically, you have to enable the interrupt manually after the critical
CPU register and OS state is saved.

interrupt can be interrupted to handle a higher priority one (I believe the
> latter is what is usually refered to as "nested interrupts")
> * How does enter_critical_section() deal with priorities? How do I know
> which priority is masked and which one isn't?
>

The critical section always mask all interrupts, but there is a special
feature(Zero Latency Interrupts) on Cortex-M:
https://cwiki.apache.org/confluence/display/NUTTX/High+Performance%2C+Zero+Latency+Interrupts
We enable this feature to fix the same issue two years ago.
But many code abuses the critical section and sched lock in many places, we
should address these problems gradually by:
1.Replace the critical section to semaphore if suitable
2.Replace the critical section to spin lock if suitable
3.Break the large critical section into several small one
These changes not only reduce the interrupt latency, but also increase the
performance in the SMP case.


> * Which configs should I enable to try this?
>
> Thanks,
> Matias


On Mon, Oct 26, 2020 at 4:52 AM Matias N.  wrote:

> Hi,
> while working on nRF52 BLE link-layer I experienced some problems due to
> delayed ISRs. This can be quite problematic
> for handling all the tight timings required by the standard. I eventually
> reached an implementation that can deal with this relatively well (BLE
> standard gives some leeway for some small number of dropped packets and
> also retransmits missing ones). However, as other peripherals start
> generating more interrupts, this could actually become a problem. Also, I
> think it would be good to know BLE ISRs will always have priority.
>
> I've been looking into how ISRs can be prioritized but I don't have much
> experience with this, so I have some questions:
> * Does nRF52 need explicit support for handling interrupts with different
> priorities or is the support supposed to be taken care of at the ARM level
> code?
> * How well supported is this in nRF52/ARM?
> * Do interrupt priorities imply nested interrupts? It isn't clear to me if
> priorities only mean which ISR will get served first when they are pending
> together or if it also implies that a low priority interrupt can be
> interrupted to handle a higher priority one (I believe the latter is what
> is usually refered to as "nested interrupts")
> * How does enter_critical_section() deal with priorities? How do I know
> which priority is masked and which one isn't?
> * Which configs should I enable to try this?
>
> Thanks,
> Matias

Re: interrupt priorities on nRF52

[David Sidrane]

Nuttx does not support nested iteruups. In fact if you enable
prioritization, you will get random crashes due to the reentrace to the
common isr.

On Sun, Oct 25, 2020, 1:52 PM Matias N.  wrote:

> Hi,
> while working on nRF52 BLE link-layer I experienced some problems due to
> delayed ISRs. This can be quite problematic
> for handling all the tight timings required by the standard. I eventually
> reached an implementation that can deal with this relatively well (BLE
> standard gives some leeway for some small number of dropped packets and
> also retransmits missing ones). However, as other peripherals start
> generating more interrupts, this could actually become a problem. Also, I
> think it would be good to know BLE ISRs will always have priority.
>
> I've been looking into how ISRs can be prioritized but I don't have much
> experience with this, so I have some questions:
> * Does nRF52 need explicit support for handling interrupts with different
> priorities or is the support supposed to be taken care of at the ARM level
> code?
> * How well supported is this in nRF52/ARM?
> * Do interrupt priorities imply nested interrupts? It isn't clear to me if
> priorities only mean which ISR will get served first when they are pending
> together or if it also implies that a low priority interrupt can be
> interrupted to handle a higher priority one (I believe the latter is what
> is usually refered to as "nested interrupts")
> * How does enter_critical_section() deal with priorities? How do I know
> which priority is masked and which one isn't?
> * Which configs should I enable to try this?
>
> Thanks,
> Matias

RE: nuttx\arch\arm\src\stm32h7\stm32_spi.c uses txresult even when SPI_DMA is not defined

[David Sidrane]

Hi Edi,



You would fork https://github.com/apache/incubator-nuttx and submit a PR
from your fork.



I will have a look at the PR on Monday when I back at the computer.



David



*From:* Eduard Niesner [mailto:niesneredu...@gmail.com]
*Sent:* Friday, October 16, 2020 10:28 AM
*To:* dev@nuttx.apache.org
*Subject:* Re: nuttx\arch\arm\src\stm32h7\stm32_spi.c uses txresult even
when SPI_DMA is not defined



I attached it as .txt.



*Please note:* I made the code build and the SPI seems to work as expected
- I am communicating with an at45db flash over SPI and mounted smartFS on
it and the communication seems to work. I am not sure if the changes that I
did are enough or if the entire spi_interrupt function should be surrounded
by the #ifdef CONFIG_STM32H7_SPI_DMA condition as well (and also where it
is called from).

It would be good if someone with more experience that understands the
impact of the change could look into it.



PS: If the changes look ok, I will register on github and create the pull
request.  Do I need to get any approvals to create branches or pull
requests on nuttx incubator?



Edi







On Fri, Oct 16, 2020 at 7:28 PM Alan Carvalho de Assis 
wrote:

Hi Eduard,

Unfortunately the mailing list is refusing patches with extension
.patch, we need to rename it to .txt to get it here.

BTW, you can submit a Pull Request directly to
https://github.com/apache/incubator-nuttx and we could review it.

BR,

Alan

On 10/16/20, Eduard Niesner  wrote:
> Hi all,
>
> I am not familiar with the code from
nuttx\arch\arm\src\stm32h7\stm32_spi.c
> but I believe that there is an issue.
> "txresult" is defined and used only if the CONFIG_STM32H7_SPI_DMA is
> defined.
> But in the spi_interrupt function, the txresult is used regardless of
> whether CONFIG_STM32H7_SPI_DMA is defined or not.
>
> This generates a build issue when you configure SPI without
> CONFIG_STM32H7_SPI_DMA.
>
> Is there anyone that knows more about this?
> I implemented a fix and it seems to be working - but since I am not
> familiar with the code I am not sure if this is the right thing to do.
> I attached a patch.
>
> Thanks,
> Edi
>

RE: Stack overflow during system init.

[David Sidrane]

Hi Fotis,


>NuttX is not able to boot at all with this option selected. I stepped
>through the code and it seems that nxsig_initialize actually causes a stack
>overflow that is detected by the above check.
>Is this a bug, or I should configure something in a different way?

Have you seen
https://cwiki.apache.org/confluence/display/NUTTX/ARMv7-M+Run+Time+Stack+Checking

We have this working in PX4.  'make px4_fmuv5_stackcheck' as of NuttX master
a few weeks ago You can see it passing on the hardware test rack

the last entry is px4_fmu-v5_stackcheck

http://ci.px4.io:8080/blue/organizations/jenkins/PX4_misc%2FFirmware-hardware/detail/master/2374/pipeline

It is most likely a configuration and build issue. (Albet the SW stack
coloring is broken on master and under repair curretly)

The __stack_overflow_trap should carry  __attribute__
((no_instrument_function))

Also R10 has to be preserved.

All files built in the build have to have the same CONFIG_ARMV7M_STACKCHECK
settings.

The margin is artificially set.

Are you using a separate interrupt stack?

With a lot of the new changes, we can assume the init path's nesting level
has not been kept small.

Increase the idle stack size by a lot (1024) and retest.


David

-Original Message-
From: Fotis Panagiotopoulos [mailto:f.j.pa...@gmail.com]
Sent: Tuesday, October 06, 2020 12:40 PM
To: dev@nuttx.apache.org
Subject: Stack overflow during system init.

Hi everyone,

I just enabled CONFIG_ARMV7M_STACKCHECK, as I would like to have this
functionality in my project, but I am facing problems.

NuttX is not able to boot at all with this option selected. I stepped
through the code and it seems that nxsig_initialize actually causes a stack
overflow that is detected by the above check.
Is this a bug, or I should configure something in a different way?

Then I realized that __stack_overflow_trap is broken.
When a stack overflow happens, this function is called which is supposed to
cause a hardfault. However as __stack_overflow_trap is a function itself,
__cyg_profile_func_enter is called again. Once again it detects the
overflow and calls __stack_overflow_trap, and so on...

Finally, as I see, the stack check is performed while entering a function,
which is wrong. If there is a stack overflow, it will be detected at the
next function call, which may be at a irrelevant part of the code. I
believe that the check shall be performed on the exit of a function, in
which case you will be sure that this specific function caused the
overflow. And of course it will solve the issue above with
__stack_overflow_trap.

RE: Stack size alignment on arm

[David Sidrane]

Hi Johannes & Jukka,

Thank you for looking into this, I just wanted to mention something, so it
does not get over looked, if it is still appropriate:

In the past (9 or so years ago) there was an issue with floating point that
required the stack to be 8 byte aligned. It was too long ago, so I do not
remember the details, j
(There is a note in the release notes, "ARM EABI: Fix stack alignment
required for passing floating point values.") But I do remember that printf
printed garbage until the STACK_ALIGN_ stuff was done.

Regards,

David


-Original Message-
From: Schock, Johannes - NIVUS GmbH [mailto:johannes.sch...@nivus.com]
Sent: Friday, September 25, 2020 5:49 AM
To: dev@nuttx.apache.org
Subject: RE: Stack size alignment on arm

> 1. Set the stack size as aligned already in
> arch/arm/src/common/arm_createstack.c:
>
> -  tcb->adj_stack_size = stack_size;
> +  tcb->adj_stack_size = STACK_ALIGN_DOWN(stack_size);
>
> 2. fix the do_stackcheck in a way that it doesn't start at (unaligned)
> top, but at the first aligned stack address?
>
> 3. just leave nuttx as is, and go fix all the stack sizes in px4?
>
>
> Initally I did the (1.) which seems to fix my problem.

I had a look, and you're right. I've missed that arm_stack_color and
do_check are now working differently concerning calculation of top
(stackbase) address.
If you don't mind (and since it is my mistake) I will provide a fix that
weekend.
Perhaps 32bit downalign instead of 32bit upalign the arm_stack_color
stackbase would also be a solution as well, since TLS size is also 32bit
aligned. This would keep the requested size in tcb->adj_stack_size.
But I have to verify with arm_usestack.c

Johannes

RE: Is the only option for using the network monitor....

[David Sidrane]

Hi Anthony & Greg,

I tested that the F7 can do simultaneous management and link operations, as
can the PHY used

I did paths 1 and 2 that we disused and the PRs are
https://github.com/apache/incubator-nuttx/pull/1886 and
https://github.com/apache/incubator-nuttx-apps/pull/402

Anthony do you have write access now?

It is IPv4 only, at the moment.

Usage is here
https://github.com/PX4/Firmware/blob/fea0858f3c378fe35be489cb07ba2241ff002c69/src/systemcmds/netman/netman.cpp#L433-L448

Doc for that app are here
https://github.com/PX4/Firmware/commit/5148fc753ae2001eb2fee6611bf01d09223eaa21

David

-Original Message-
From: Anthony Merlino [mailto:anth...@vergeaero.com]
Sent: Thursday, September 17, 2020 1:17 PM
To: dev@nuttx.apache.org
Subject: Re: Is the only option for using the network monitor

David,

I've been trying to figure out how you would do this on Linux. This seems
to be the right answer. Done via a "lease" configuration for dhcpd, or via
secondary static IP on the interface
https://stackoverflow.com/questions/12727175/set-static-ip-if-not-obtained-from-dhcp-script

For your purposes, I think there would be a few paths:

   1. Modify the netinit logic to attempt connection over DHCP, but on
   failure to connect to the server, fallback and setup the DHCP.
   2. Modify DHCP logic to support fallback static IP via configuration
   similar to lease.
   3. Add support for multiple IP addresses on a single interface within
   the network stack. Then always assign the static IP in addition to the
one
   DHCP may or may not setup.
   This is a big job, but I'd really like to see us get it done at some
   point. Right now, for IPv6, AFAIK, we can't even support a link-local IP
   address (fe80::/10 with a global IP at the same time.


On Thu, Sep 17, 2020 at 4:02 PM Gregory Nutt  wrote:

> On 9/17/2020 1:59 PM, David Sidrane wrote:
> >   Is the only option for using the network monitor
> >
> > Hi,
> >
> > My goal is to have a run time option to use a static IP or DHCP.
> (Curretly
> > it is compile time)
> >
> > If either are used I want to "auto up" the eth0. Once the interface
> comes up
> > , if configured for DHCP it should make start the DHCP request process.
> >
> > Is the only option for using the network monitor to have phy interrupts
> or
> > is there a polled option?
> >
> > David
> >
> There is no polled option.  I am not certain if you can access the PHY
> while in normal operating mode either.  Doesn't management mode disable
> the MAC?
>
>

RE: Is the only option for using the network monitor....

[David Sidrane]

Hi Greg,

Thank you responding. Then I will I will test it.

-Original Message-
From: Gregory Nutt [mailto:spudan...@gmail.com]
Sent: Thursday, September 17, 2020 1:03 PM
To: dev@nuttx.apache.org
Subject: Re: Is the only option for using the network monitor

On 9/17/2020 1:59 PM, David Sidrane wrote:
>   Is the only option for using the network monitor
>
> Hi,
>
> My goal is to have a run time option to use a static IP or DHCP. (Curretly
> it is compile time)
>
> If either are used I want to "auto up" the eth0. Once the interface comes
> up
> , if configured for DHCP it should make start the DHCP request process.
>
> Is the only option for using the network monitor to have phy interrupts or
> is there a polled option?
>
> David
>
There is no polled option.  I am not certain if you can access the PHY
while in normal operating mode either.  Doesn't management mode disable
the MAC?

Is the only option for using the network monitor....

[David Sidrane]

 Is the only option for using the network monitor

Hi,

My goal is to have a run time option to use a static IP or DHCP. (Curretly
it is compile time)

If either are used I want to "auto up" the eth0. Once the interface comes up
, if configured for DHCP it should make start the DHCP request process.

Is the only option for using the network monitor to have phy interrupts or
is there a polled option?

David

PR's without adequate information

[David Sidrane]

 PR's without adequate information

We are getting a slew of PR's without adequate information to consider
merging them. Some of the Titles are incomplete or misleading.

I am also concerned about bloat and the loss of one of NuttX major
advantages: Scalability.

I have no doubt, there is a great deal of value being added but for* only
some users**.* The changes are coming in with no way to disable them.

I would ask that PR have all the description sections filled in and provide
justification.

I have seen this asked for repeatedly by several of the committers. We
also have
some excellent examples now or PRs that offer great context. Please model
your submission after those PR.

Helping a reviewer gain the context, of Why, How, and What, will speed
PR review
and acceptance. Having to look at a PR and infer the intent waste of
everyone's time.

David

RE: i.MX RT 1060 ADC

[David Sidrane]

Hi Thomas,

If you structure the driver like any of the other ADC drivers in tree you
should be able to reference px4_arch_adc_init and px4_arch_adc_sample

from
https://github.com/PX4/Firmware/blob/master/platforms/nuttx/src/px4/nxp/im
xrt/adc/adc.cpp to get the required logic.

To fill in the meat, but you will have to do it in nuttx style using the
{get|set}reg32 calls.

David

-Original Message-
From: Thomas Axelsson [mailto:thomas.axels...@actia.se]
Sent: Tuesday, September 15, 2020 2:55 AM
To: dev@nuttx.apache.org
Subject: i.MX RT 1060 ADC

Hi,

I'm looking into using the ADC on IMXRT 1060. I have found imxrt_adc.h and
some examples in nuttx-apps using /dev/adcXX. However, it seems that the
actual functionality is not yet implemented for IMXRT.

So I'm looking into implementing this driver, based on e.g. lpc17_40_adc.c
(diffing all *_adc.c files turned up almost no differences). I tried
grepping for some register names to see if the IP block is already
implemented for another chip, but without luck.

I'm sending this e-mail to see if someone else is already working on the
same thing. I did see that imxrt_adc.h has gotten some updates.

Thomas Axelsson
SW Developer
ACTIA Nordic AB (part of ACTIA Group)

Mail: thomas.axels...@actia.se
Web: www.actia.se

RE: stm32 uart init bug?

[David Sidrane]

I was not suggesting the fix should be in the boot loader, I was just
commenting on what the right way to do a boot loader.

I am sure the F4/F7 serial drivers deal with the PE bits. It has many test
cases in the RC lib of PX4, it the low level stuff that most likely does not
work correctly
And should be fixed. Consider using the RCC  peripheral reset register
to get to ground state for the UxART then it should be very straight
forward.
RESET STATE + config chosen.

David

-Original Message-
From: Nathan Hartman [mailto:hartman.nat...@gmail.com]
Sent: Friday, September 04, 2020 7:42 AM
To: dev@nuttx.apache.org
Subject: Re: stm32 uart init bug?

On Fri, Sep 4, 2020 at 9:46 AM Gregory Nutt  wrote:

>
> > Sometimes the best results (on small systems) are obtained if boot
> > loader
> > leaves the CPU as it found it out of reset.
> >
> > If you think in terms of an OOD life cycle: The "Destructor" for each
> block
> > reset the HW to the reset state.
> >
> > With this approach, the SoC out of reset, and executing at __start  from
> the
> > bootloader are 100% documented by the information the data sheet and the
> > reference manual.
> You would still need to disable the UART in the STM32 code in order to
> re-configure partity (and maybe other planners).  So the solution is in
> stm32_lowputc.c, not in the bootloader.
>

Agreed. Fixing that there will prevent others from encountering similar
problems, regardless whether there's a bootloader involved or not.

To David's point, I agree the bootloader should be well behaved and restore
initial conditions before it exits.

I intend to fix both for correctness. PR coming soon for stm32_lowputc.c.

Nathan

RE: stm32 uart init bug?

[David Sidrane]

Nathan,

Sometimes the best results (on small systems) are obtained if boot loader
leaves the CPU as it found it out of reset.

If you think in terms of an OOD life cycle: The "Destructor" for each block
reset the HW to the reset state.

With this approach, the SoC out of reset, and executing at __start  from the
bootloader are 100% documented by the information the data sheet and the
reference manual.


David

-Original Message-
From: Nathan Hartman [mailto:hartman.nat...@gmail.com]
Sent: Thursday, September 03, 2020 7:08 PM
To: dev@nuttx.apache.org
Subject: Re: stm32 uart init bug?

On Thu, Sep 3, 2020 at 7:38 PM Gregory Nutt  wrote:

> Perhaps:
>
> Bit 10PCE: Parity control enableThis bit selects the hardware parity
> control (generation and detection). When the parity control is enabled,
> the computedparity is inserted at the MSB position (9th bit if M=1; 8th
> bit if M=0) and the parity is checked on the received data. This bit is
> set and cleared by software. Once it is set, PCE is active after the
> current byte (in reception and in transmission).0: Parity control
> disabled1: Parity control enabled/*This bitfield can only be writte*//*n
> when the USART is disabled (U*//*E=0).*/
>
> Bit 9PS: Parity selectionThis bit selects the odd or even parity when
> theparity generation/detection is enabled (PCE bit set). It is set and
> cleared by software.The parity is selected after the current byte.0:
> Even parity1: Odd parityT/*his bitfield can only be writte*//*n when the
> USART is disabled (U*//*E=0)*/


Yes, that looks like the culprit, in combination with the bootloader not
being well behaved.

I think we should ensure the USART is disabled before attempting to
configure it. This probably was never caught before because it doesn't
manifest as long as NuttX starts out of reset, or people who used serial
bootloaders were using the more common 8N1 setting, or they were using a
more well-behaved bootloader.

In any case, I think it's best to ensure that we can configure the UART
successfully no matter the initial conditions.

I'll try to get a PR tomorrow. It's been a long day.

Separately, I need to implement a custom bootloader for various reasons, so
I'll make sure it performs a complete teardown before launching NuttX. :-)

Thanks for your help,
Nathan

Re: stm32 uart init bug?

[David Sidrane]

Some IP blocks need to be disabled to modify some registers.

David

On Thu, Sep 3, 2020, 3:45 PM Nathan Hartman 
wrote:

> I ran into a strange issue with serial init for STM32. If the UART is
> already enabled/configured, our configuration does not seem to apply.
>
> I discovered this because I used a bootloader to flash and run NuttX
> on the arm/stm32/b-g474e-dpow1 board. The bootloader configs the UART
> for 115200 baud 8E1.
>
> This is how nsh looks if I type 'help' command:
>
> nsh> [hp
> hp usag  hp [v] [md>]
>
>d  smvs   unam
>   [ p  mbmsp umun
>mp   as mkd pnsuuns
>   basnam  dnam   hp  mkd  pd   s  usp
>   bak ddhdump   mhmm  d
>   a   h  k  mun md u
> nsh> [
>
> This is because Even Parity (and possibly other stale config) is still
> in effect from the bootloader.
>
> When I flash and run NuttX without the bootloader, the nsh prompt
> works correctly with 115200 baud 8N1.
>
> Has anyone seen this before?
>

RE: Color ANSI support in nsh

[David Sidrane]

Hi Christian,

As long as there is a Knob in Kconfig to enable / disable each feature (that
defaults to disable) the impact is 0.

IIRC there is a history, and some fancy-ness that was added by Dave a while
ago. Good docs and an example defconfig would will keep it maintained (and
built). Once we have scripted test running against the sim (or real HW) test
cases will keep it from breaking.

David

-Original Message-
From: Christian Catchpole [mailto:christ...@catchpole.net]
Sent: Saturday, August 15, 2020 5:52 PM
To: dev@nuttx.apache.org
Subject: Color ANSI support in nsh

Hi everyone,

I have been adding ANSI escape codes for colour support to my app’s console
output and have been experimenting with adding it to nsh itself. At a
minimum to colour the prompt.

I had been thinking this is something i could develop and propose to come
back into the mainline as a nsh kconfig option.

But before i do, the obvious question is, has this been proposed before and
are there reasons we wouldn’t want this in NuttX?

I’m also thinking it would be good to have a single line of command
history. Other configurable options could be clear screen on nsh entry (I
added this as my app was using ANSI line positioning and resets back into
nsh looked messy). There are all sorts of fun things which could be done
with ANSI terminal emulation.

Thanks,
See you all tonight. Where you’ll see my demo going crazy with ANSI colour
codes.

Christian

RE: Roadmap?

[David Sidrane]

+1 (I know it is not a vote, I am just agreeing)

-Original Message-
From: Brennan Ashton [mailto:bash...@brennanashton.com]
Sent: Wednesday, August 12, 2020 10:54 AM
To: dev@nuttx.apache.org
Subject: Re: Roadmap?

On Wed, Aug 12, 2020, 10:40 AM Adam Feuer  wrote:

> Folks,
>
> I made a wiki page with the raw list of things that people are asking for
> in this thread:
>
> https://cwiki.apache.org/confluence/display/NUTTX/Roadmap


I am thinking this might be easier to manage as GH tickets with a label,
and then link on a project board if we want an overview. The thing I really
don't like about the wiki is you need an Apache account to add things which
creates an unfortunate barrier to it and it is even harder to then link to
PRs and code.

In a couple other projects we had a process where people could bring
forward something like a NuttX Feature Proposal (NFP) where it would be
outlined and the details sorted possibly some PoC done if it was large and
then it could be accepted and executed on.  This is a slow process that is
not a bad thing for major changes that have a lot of implications.

RE: Roadmap?

[David Sidrane]

Github project boards or confluence?

-Original Message-
From: Gregory Nutt [mailto:spudan...@gmail.com]
Sent: Wednesday, August 12, 2020 9:07 AM
To: dev@nuttx.apache.org
Subject: Re: Roadmap?


> I am interested in industrial devices communicating by fieldbuses. I use
> the NuttX port of FreeModbus stack and I would like to see more port of
> communication stacks like this. I prefer CANopen and Profinet, There are
> several open source communication stack for these protocols.

Where would we document a roadmap?  How/who would prioritize and
schedule implementation of roadmap items?  How could accomplish any of
this with only a volunteer organization and no project management with
any authority?

RE: Board-specific drivers in NuttX 9.1.0.

[David Sidrane]

I am volunteering to help test any of these type changes. There were many
subtle breakages in the past that tended to slip through. Also once all this
settles out, it so needs to be documented.

-Original Message-
From: Abdelatif Guettouche [mailto:abdelatif.guettou...@gmail.com]
Sent: Wednesday, August 12, 2020 6:41 AM
To: dev@nuttx.apache.org
Subject: Re: Board-specific drivers in NuttX 9.1.0.

Note that this common board organisation and these two folders are
relatively new and didn't get as much attention as they need.
That said, I like the second suggestion.  Would you like to prepare a
PR and see what others have to say?  I could do that if you want.

On Wed, Aug 12, 2020 at 12:31 PM Fotis Panagiotopoulos
 wrote:
>
> Thank you very much.
> Indeed it now works perfectly.
>
> However I would propose a little change on this.
> Currently board drivers require a specific directory structure, and this
> non-obvious (for me) config entry.
>
> Why not instead handle external drivers exactly like external boards?
> That is, add CONFIG_ARCH_DRIVERS_CUSTOM, CONFIG_ARCH_DRIVERS_CUSTOM_DIR,
> CONFIG_ARCH_DRIVERS_CUSTOM_DIR_RELPATH etc in nuttx/drivers/Kconfig and
> have the user select whether they need external drivers and where should
> they be located, instead of implying things.
>
> Or, at a minimum, I believe CONFIG_SPECIFIC_DRIVERS could be defined in
> nuttx/drivers/Kconfig. Since the build system uses this symbol, nuttx
> should define it, instead of relying on external Kconfigs.
>
> Στις Τετ, 12 Αυγ 2020 στις 2:02 μ.μ., ο/η Abdelatif Guettouche <
> abdelatif.guettou...@gmail.com> έγραψε:
>
> > > It's the drivers/Kconfig that
> > defines it (i.e. you add it), you can then enable it from menuconfig.
> >
> > To be clear I meant the "drivers" folder that's linked to "platform"
> > not the toplevel nuttx/drivers.
> >
> > On Wed, Aug 12, 2020 at 12:51 PM Abdelatif Guettouche
> >  wrote:
> > >
> > > As far as I can tell it's the same, current master[1], 9.1[2], 9.0[3],
> > 8.1[4]
> > > I do have some flashes about the necessity of a drivers folder
> > > alongside the board folder with custom boards, but I can't remember.
> > > That was an issue, it's now resolved.
> > >
> > > > But the code is not included in the build. I checked my Make.defs,
> > > > and
> > it
> > > > is similar to other Make.defs of the other drivers:
> > >
> > > You need CONFIG_SPECIFIC_DRIVERS set.  It's the drivers/Kconfig that
> > > defines it (i.e. you add it), you can then enable it from menuconfig.
> > >
> > > 1.
> > https://github.com/apache/incubator-nuttx/tree/master/boards/arm/cxd56xx
> > > 2.
> > https://github.com/apache/incubator-nuttx/tree/releases/9.1/boards/arm/cxd56xx
> > > 3.
> > https://github.com/apache/incubator-nuttx/tree/releases/9.0/boards/arm/cxd56xx
> > > 4.
> > https://github.com/apache/incubator-nuttx/tree/nuttx-8.1/boards/arm/cxd56xx
> > >
> > >
> > > On Wed, Aug 12, 2020 at 10:57 AM Fotis Panagiotopoulos
> > >  wrote:
> > > >
> > > > > NB: You'll need this patch too:
> > > > > https://github.com/apache/incubator-nuttx/pull/1480
> > > > 
> > > >
> > > > Oh, I didn't realize that I had to patch v9.1.0 with this. I thought
> > it was
> > > > already included in the latest releases. After patching, linking of
> > > > my
> > > > drivers folder into nuttx/drivers/platform works.
> > > > Kconfig is parsed, and the new options appear in menuconfig.
> > > > But the code is not included in the build. I checked my Make.defs,
> > > > and
> > it
> > > > is similar to other Make.defs of the other drivers:
> > > >
> > > > CSRCS += driver.c
> > > > DEPPATH += --dep-path platform
> > > > VPATH += :platform
> > > > CFLAGS += $(shell $(INCDIR) "$(CC)"
> > > > $(TOPDIR)$(DELIM)drivers$(DELIM)platform)
> > > >
> > > >
> > > > > The structure has not changed, Xiang patch made it possible to
> > > > > omit
> > > > > the "drivers" folder when it's not needed, in that case a dummy
> > folder
> > > > > is linked
> > > >
> > > > As I see, in v9.0.0, the structure was:
> > > > └── boards_dir
> > > > └── board1
> > > > └── drivers
> > > >
> > > > but in v9.1.0 it is
> > > > └── boards_dir
> > > > ├── board1
> > > > └── drivers
> > > >
> > > > or am I missing anything?
> > > >
> > > >
> > > > Στις Τετ, 12 Αυγ 2020 στις 5:22 π.μ., ο/η Xiang Xiao <
> > > > xiaoxiang781...@gmail.com> έγραψε:
> > > >
> > > > > You can try
> > > > >
> > https://github.com/apache/incubator-nuttx/tree/master/boards/arm/cxd56xx
> > > > > and compare the difference with yours.
> > > > >
> > > > > > -Original Message-
> > > > > > From: Nathan Hartman 
> > > > > > Sent: Wednesday, August 12, 2020 5:34 AM
> > > > > > To: dev@nuttx.apache.org
> > > > > > Subject: Re: Board-specific drivers in NuttX 9.1.0.
> > > > > >
> > > > > > On Tue, Aug 11, 2020 at 1:14 PM Fotis Panagiotopoulos <
> > > > > f.j.pa...@gmail.com>
> > > > > > wrote:
> > > > > >
> > > > > > The