Re: SD FAT32: Write failed with err 28 (no space left on device)

[Bob Feretich]

Just a thought
On M7 devices, the DMA buffers need to be cache line aligned. Nuttx has
special malloc functions configurable for FAT buffers.

Also, I'm  not sure the cache invalidate code was tested well for
store-into cache mode. Store-through was known to be working.

-Bob

On Fri, Sep 18, 2020, 3:11 AM Oleg Evseev  wrote:

> I've debugged this issue and found out that in such moments fs_buffer is
> not filled fully - if I read the same cluster from pc - fat chain is ok.
>
> Moreover I found that after a few steps in debug fs_buffer gets fully
> filled as it is on an sd card. So it looks like the issue is related to
> hardware read using dma (CONFIG_STM32F7_DMACAPABLE=y,
> CONFIG_STM32F7_SDMMC_DMA=y).
> MCU is stm32f767
>
> It doesn't happen every time, but quite rare. Any thoughts where should I
> look further?
>
> пн, 7 сент. 2020 г. в 10:49, Oleg Evseev :
>
>> Hi all,
>>
>> I'm working with stm32f7 custom board and px4 firmware, but my concerns
>> are with the NuttX FAT32 driver. I have an issue. PX4 logger module writes
>> high rate data to SD card successfully awhile, until at some point write
>> func return error 28 (“No space left on device”) while there is a lot of
>> free space on a card (29GB out of 30GB).
>>
>> I had this error several times on two different SD-cards. I don't do a
>> lot of tests, but it seems that SanDisk Extreme Pro is less prone - it can
>> write 100+ Mbytes files without errors, while SanDisk Extreme usually
>> breaks a little earlier.
>> The board is on the table, no vibrations (at least any significant).
>>
>> I dig a little and can see that 'fat_write' try to extend the current
>> cluster by one calling 'fat_extendchain' func that on existing chain
>> extending verifies that this is a valid cluster by examining its start
>> sector, but 'startsector = fat_getcluster(fs, cluster);' returns 0:
>>
>>  else if (startsector < 2)
>> {
>>   /* Oops.. this cluster does not exist. */
>>   return 0;
>> }
>>
>> In 'fs_buffer' there is indeed 0 for this fatindex (see picture).
>> [image: изображение.png]
>>
>>
>> I didn't dig much in the driver and fat32 itself. What should I check,
>> where it is useful to set breakpoints, etc.?
>>
>> Can any hardware issues be the reason for such error theoretically?
>> Can any previous power shutdown and unfinished writings (in fact
>> shutdowns can be on every launch and I already have several corrupted
>> files), breaks FAT system itself in that way it can lead to this exact
>> error for new sessions?
>>
>> Thanks in advance for any help!
>>
>> ---
>> With regards, Oleg.
>>
>

Re: SD FAT32: Write failed with err 28 (no space left on device)

[Bob Feretich]

By the way, the signature of this problem is corruption of either the 
first or last 16 bytes of a 512-byte sector.
The M7 cache line size is 32 bytes. The standard Nuttx malloc uses a 
16-byte alignment. Losing 16-bytes of a FAT table or directory  will 
cause all sorts of strange things to occur.


Regards,
Bob

On 9/18/2020 8:54 AM, Bob Feretich wrote:

Just a thought
On M7 devices, the DMA buffers need to be cache line aligned. Nuttx 
has special malloc functions configurable for FAT buffers.


Also, I'm  not sure the cache invalidate code was tested well for 
store-into cache mode. Store-through was known to be working.


-Bob

On Fri, Sep 18, 2020, 3:11 AM Oleg Evseev > wrote:


I've debugged this issue and found out that in such moments
fs_buffer is not filled fully - if I read the same cluster from pc
- fat chain is ok.

Moreover I found that after a few steps in debug fs_buffer gets
fully filled as it is on an sd card. So it looks like the issue is
related to hardware read using dma (CONFIG_STM32F7_DMACAPABLE=y,
CONFIG_STM32F7_SDMMC_DMA=y).
MCU is stm32f767

It doesn't happen every time, but quite rare. Any thoughts where
should I look further?

пн, 7 сент. 2020 г. в 10:49, Oleg Evseev mailto:ev.m...@gmail.com>>:

Hi all,

I'm working with stm32f7 custom board and px4 firmware, but my
concerns are with the NuttX FAT32 driver. I have an issue. PX4
logger module writes high rate data to SD card successfully
awhile, until at some point write func return error 28 (“No
space left on device”) while there is a lot of free space on a
card (29GB out of 30GB).

I had this error several times on two different SD-cards. I
don't do a lot of tests, but it seems that SanDisk Extreme Pro
is less prone - it can write 100+ Mbytes files without errors,
while SanDisk Extreme usually breaks a little earlier.
The board is on the table, no vibrations (at least any
significant).

I dig a little and can see that 'fat_write' try to extend the
current cluster by one calling 'fat_extendchain' func that on
existing chain extending verifies that this is a valid cluster
by examining its start sector, but 'startsector =
fat_getcluster(fs, cluster);' returns 0:

     else if (startsector < 2)
        {
          /* Oops.. this cluster does not exist. */
          return 0;
        }

In 'fs_buffer' there is indeed 0 for this fatindex (see picture).
изображение.png


I didn't dig much in the driver and fat32 itself. What should
I check, where it is useful to set breakpoints, etc.?

Can any hardware issues be the reason for such error
theoretically?
Can any previous power shutdown and unfinished writings (in
fact shutdowns can be on every launch and I already have
several corrupted files), breaks FAT system itself in that way
it can lead to this exact error for new sessions?

Thanks in advance for any help!

---
With regards, Oleg.

Re: Nuttx for Nucleo-F429ZI

[Flavio Castro Alves Filho]

Well,

I don't know how to explain, but I was reviewing here the process for
setup, writing down the commands that I used ... and now everything is
working fine. :-/

Maybe during yesterday's tests maybe something may be lost
during menuconfig.

I am sorry for the inconvenience.

But ... maybe I found my answer. I believe that the
nucleo-f429zi:netnsh is the configuration that I was looking for.

The problem that I am facing now is that is that the network interface
is not initializing:

nsh> ifconfig
nsh: ifconfig: opendir failed: 20

Best regards,,

Flavio


Em sex., 18 de set. de 2020 às 20:16, Brennan Ashton
 escreveu:

>
> On Fri, Sep 18, 2020 at 3:16 PM Flavio Castro Alves Filho
>  wrote:
> >
> > Hello Matias,
> >
> > Em sex., 18 de set. de 2020 às 16:26, Matias N.  escreveu:
> > >
> > > Hi Flavio,
> > > please have a look at our new documentation, which you may find helpful:
> > >
> > > https://nuttx.apache.org/docs/latest/
> > >
> >
> > I did ... that's how I found most of the problems to have this initial
> > version running.
> >
> > > Most boards have a "nsh" documentation which should be a good start (this
> > > is also explained in the documentation).
> > >
> >
> > ok. I will check this out.
> >
> > > I don't know the particular status of this board, but usually STM32 
> > > boards are
> > > well supported.
> > >
> >
> > Probably there is something with this board.
> >
> > > Best,
> > > Matias
> > >
> >
> > Thank you for your response.
> >
> > Best regards,
> >
> > Flavio
>
> Flavio,
> I do have the STM32F439ZI version which as far as NuttX is concerned
> should be the same.  I can give it a try this weekend, in the meantime
> if you could post your steps and where you got stuck in an issue, we
> can work through exactly what went wrong and fix the documentation.
>
> --Brennan



--
Flavio de Castro Alves Filho

flavio.al...@gmail.com
Twitter: http://twitter.com/#!/fraviofii
LinkedIn profile: www.linkedin.com/in/flaviocastroalves

Re: Warnings in Renesas common files

[Xiang Xiao]

Bhindhiya,
Why not follow the approach taken by other arch?

On Fri, Sep 18, 2020 at 9:34 PM Bhindhiya Raja
 wrote:
>
> Hello Team,
>
> We are trying to include Renesas RX65N architecture in GitHub pre-check which 
> requires code to have 0 warnings to be successful.
>
> Call to up_copystate() in the below functions produces warnings in NuttX 
> common files:
> arch/renesas/src/common/up_blocktask.c: up_block_task()
> arch/renesas/src/common/up_releasepending: up_release_pending()
> arch/renesas/src/common/up_reprioritizertr: up_reprioritize_rtr()
> arch/renesas/src/common/up_unblocktask: up_unblock_task()
>
> Changes in the above files will affect the other Renesas architectures (m16c 
> and sh1) as well.
>
> The function prototype of up_copystate() in file: 
> "arch/renesas/src/common/up_internal.h" is as follows:
> void up_copystate(uint32_t *dest, uint32_t *src);
>
> g_current_regs is also defined in the same file as:
> extern volatile uint32_t *g_current_regs;
>
> Calling up_copystate() with g_current_regs as 2nd argument gives the 
> following warning:
> passing argument 2 of ‘up_copystate’ discards ‘volatile’ qualifier from 
> pointer target type [-Werror]
> up_copystate(rtcb->xcp.regs, g_current_regs);
> ^
>
> The above call causes the 'volatile' nature of g_current_regs to be lost.
> We understand that casting away the 'volatile' type qualifier of a variable 
> should be avoided if possible.
>
> We intend to do a PR by modifying the prototype of the above function to:
> void up_copystate(uint32_t *dest, volatile uint32_t *src);
> This modification produces the same warning in memcpy() function call.
> Typecasting the argument when calling memcpy() alone will resolve this 
> warning.
>
> This retains the volatile nature of the variable as well as resolves the 
> warnings produced
> due to the above function call with volatile g_current_regs argument.
>
> Are there any concerns with the above mentioned modifications?
>
> Regards,
> Bhindhiya Raja.
> 
> From: Bhindhiya Raja 
> Sent: Monday, September 14, 2020 5:09 PM
> To: dev@nuttx.apache.org 
> Subject: Re: Warnings in Renesas common files
>
> Hello Greg and Nathan,
>
> Any input on the warnings generated due to the g_current_regs volatile type 
> qualifier?
>
> Best Regards,
>
> Bhindhiya Raja
>
>
> SBU | Engineer
>
> TATA ELXSI LIMITED
>
> ITPB Road Whitefield
>
> Bengaluru 560 048 India
>
> www.tataelxsi.com
>
> 
> From: Nathan Hartman 
> Sent: Saturday, September 5, 2020 3:51 AM
> To: dev@nuttx.apache.org 
> Subject: Re: Warnings in Renesas common files
>
> 
>  **This is an external email. Please check the sender’s full email address 
> (not just the sender name) and exercise caution before you respond or click 
> any embedded link/attachment.**
> 
>
> On Fri, Sep 4, 2020 at 9:40 AM Bhindhiya Raja
>  wrote:
> >
> > Hello Nathan,
> >
> > Thank you for your response. We have submitted 2 separate PRs as 
> > recommended by you to resolve warnings 6 (#1695) and 8 (#1702).
> >
> > About warnings 1 to 4, we understand that casting away the 'volatile' type 
> > qualifier of a variable should be avoided if possible. Can we consider 
> > modifying the prototype of the function up_copystate() in up_internal.h 
> > file,
> > from:
> > void up_copystate(uint32_t *dest, uint32_t *src);
> > to:
> > void up_copystate(uint32_t *dest, volatile uint32_t *src);
> > in order to resolve this warning.
> >
> > We have tried the above fix in our local repository and checked build.
> > We found that warnings 1 to 4 are resolved, however, it generates a new 
> > warning in file:
> > arch/renesas/src/rx65n/rx65n_copystate.c: passing argument 2 of 
> > ‘up_copystate’ discards ‘volatile’ qualifier from pointer target type
> > memcpy(dest, src, XCPTCONTEXT_SIZE);
> >
> > expected ‘const void *’ but argument is of type ‘volatile uint32_t *’
> > FAR void *memcpy(FAR void *dest, FAR const void *src, size_t n);
> >
> > This can be resolved by typecasting the variables when calling memcpy() 
> > alone.
> >
> > As these files are common to other Renesas architectures as well, please 
> > confirm if the above modifications are okay.
>
>
> Hello Bhindhiya,
>
> I am not sure what is the best choice here. I looked through NuttX
> sources and I did not see any up_copystate() (for any arch) that had
> volatile qualifiers. That said, looking at the call to up_copystate()
> in up_unblock_task(), g_current_regs is indeed volatile (for good
> reasons), so I wonder if we should propagate that as far as possible,
> until the memcpy(), like you're suggesting, or, alternativ

Driver Headers

[Brennan Ashton]

I am a little confused by what should be stored in the header files
for drivers in these two locations and I do not want to further any
existing mistakes:

include/nuttx//.h
and
drivers/

To mean it seems it should be organized like this:

drivers/
should be holding internal to the driver interfaces, such register
definitions, low level communication interfaces readreg, writereg,
etc... that might be shared across implementations.

include/nuttx//.h
should hold the interfaces/types required to interact with the driver,
registration, initialization, callbacks, etc... that are expected to
be used by the board integration.  As well as things like IOCTL and
types used by userspace.


Currently there are lots of examples of both and it also seems odd to
me that the header used for the internal board interfaces is also used
by user space applications.  So maybe I am very off base here.

--Brennan

Re: Driver Headers

[Gregory Nutt]

drivers/
should be holding internal to the driver interfaces, such register
definitions, low level communication interfaces readreg, writereg,
etc... that might be shared across implementations.

include/nuttx//.h
should hold the interfaces/types required to interact with the driver,
registration, initialization, callbacks, etc... that are expected to
be used by the board integration.  As well as things like IOCTL and
types used by userspace.


That seems reasonable.  I have also always kept standard definitions 
form the device specification in include/nuttx//.h 
since these are a part of the public description of the hardware and not 
part of the arbitrary driver design.  Certainly there is not 
architectural reason to obfuscate the standard specified hardware 
interface. But I also understand you could argue as you have done here.


So for me:

drivers/:
Internal driver design that should not be exposed outside of the 
driver.  Otherwise the arbitrary design could be incorporated into some 
external logic introducing a nasty coupling.


The device description from the specification is NOT part of the 
internal design (and can introduce no coupling).


include/nuttx//.h:
(1) everything that external logic needs to interface with the design, 
plus (2) all of the standard definitions from device specification that 
are totally independent of the driver design.


All driver that I have written are done this way.

Podling Nuttx Report Reminder - October 2020

[jmclean]

Dear podling,

This email was sent by an automated system on behalf of the Apache
Incubator PMC. It is an initial reminder to give you plenty of time to
prepare your quarterly board report.

The board meeting is scheduled for Wed, 21 October 2020.
The report for your podling will form a part of the Incubator PMC
report. The Incubator PMC requires your report to be submitted 2 weeks
before the board meeting, to allow sufficient time for review and
submission (Wed, October 07).

Please submit your report with sufficient time to allow the Incubator
PMC, and subsequently board members to review and digest. Again, the
very latest you should submit your report is 2 weeks prior to the board
meeting.

Candidate names should not be made public before people are actually
elected, so please do not include the names of potential committers or
PPMC members in your report.

Thanks,

The Apache Incubator PMC

Submitting your Report

--

Your report should contain the following:

*   Your project name
*   A brief description of your project, which assumes no knowledge of
the project or necessarily of its field
*   A list of the three most important issues to address in the move
towards graduation.
*   Any issues that the Incubator PMC or ASF Board might wish/need to be
aware of
*   How has the community developed since the last report
*   How has the project developed since the last report.
*   How does the podling rate their own maturity.

This should be appended to the Incubator Wiki page at:

https://cwiki.apache.org/confluence/display/INCUBATOR/October2020

Note: This is manually populated. You may need to wait a little before
this page is created from a template.

Note: The format of the report has changed to use markdown.

Mentors
---

Mentors should review reports for their project(s) and sign them off on
the Incubator wiki page. Signing off reports shows that you are
following the project - projects that are not signed may raise alarms
for the Incubator PMC.

Incubator PMC

Re: Driver Headers

[Gregory Nutt]

drivers/
should be holding internal to the driver interfaces, such register
definitions, low level communication interfaces readreg, writereg,
etc... that might be shared across implementations.

include/nuttx//.h
should hold the interfaces/types required to interact with the driver,
registration, initialization, callbacks, etc... that are expected to
be used by the board integration.  As well as things like IOCTL and
types used by userspace.


That seems reasonable.  I have also always kept standard definitions 
form the device specification in include/nuttx//.h 
since these are a part of the public description of the hardware and 
not part of the arbitrary driver design.  Certainly there is not 
architectural reason to obfuscate the standard specified hardware 
interface. But I also understand you could argue as you have done here.


So for me:

drivers/:
Internal driver design that should not be exposed outside of the 
driver.  Otherwise the arbitrary design could be incorporated into 
some external logic introducing a nasty coupling.


The device description from the specification is NOT part of the 
internal design (and can introduce no coupling).


include/nuttx//.h:
(1) everything that external logic needs to interface with the design, 
plus (2) all of the standard definitions from device specification 
that are totally independent of the driver design.


All driver that I have written are done this way.


I  can see how you can argue either way.

But networking is handled the same way: include/nuttx/net/.h 
provides all protocol define definitions from the RFC. AND it includes 
the required interface information to use the protocol.  Isn't that the 
same?


But that is not done consistently.  Most of the spec definitions fro FAT 
are in fs/fat/, not include/nuttx/fs/fat.h

Re: Driver Headers

[Gregory Nutt]

drivers/
should be holding internal to the driver interfaces, such register
definitions, low level communication interfaces readreg, writereg,
etc... that might be shared across implementations.

include/nuttx//.h
should hold the interfaces/types required to interact with the driver,
registration, initialization, callbacks, etc... that are expected to
be used by the board integration.  As well as things like IOCTL and
types used by userspace.


That seems reasonable.  I have also always kept standard definitions 
form the device specification in include/nuttx//.h 
since these are a part of the public description of the hardware and 
not part of the arbitrary driver design.  Certainly there is not 
architectural reason to obfuscate the standard specified hardware 
interface. But I also understand you could argue as you have done here.


So for me:

drivers/:
Internal driver design that should not be exposed outside of the 
driver.  Otherwise the arbitrary design could be incorporated into 
some external logic introducing a nasty coupling.


The device description from the specification is NOT part of the 
internal design (and can introduce no coupling).


include/nuttx//.h:
(1) everything that external logic needs to interface with the 
design, plus (2) all of the standard definitions from device 
specification that are totally independent of the driver design.


All driver that I have written are done this way.


I  can see how you can argue either way.

But networking is handled the same way: include/nuttx/net/.h 
provides all protocol define definitions from the RFC. AND it includes 
the required interface information to use the protocol.  Isn't that 
the same?


But that is not done consistently.  Most of the spec definitions fro 
FAT are in fs/fat/, not include/nuttx/fs/fat.h


I think only the arch/ hardware definitions handle this is a 
satisfactory way, with two separate, public header files:  One for the 
hardware definition and one for driver interface.