Good Morning Alan,
Can't really tell you why, decisions made by the hardware designer. Bet bet I
have. Unfortunately the layout is hardwired like this, so no qspi or SDIO
available without a change.
Reto
On 2021/05/19 15:27:38, Alan Carvalho de Assis wrote:
> Hi Reto,
>
> Just a curiosity:
Hello David,
I will try this option.
Thank you very much.
Best regards,
Flavio
Em qua., 19 de mai. de 2021 19:28, David Sidrane
escreveu:
> 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/pul
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
Hello Gregory,
Thank you for your quick response.
Looking at the PRs, they seemed a bit complex for me :-| And I'm not
sure if it is that what I want or need.
What I was thinking was to use this call:
stm32_phyread(CONFIG_STM32F4_PHYADDR,MII_MSR,&phyval);
Then make the check:
if ((phyval & MI
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
pollin
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
[
Hello,
Coming back to this issue.
Looking at STM32F4DISCOVERY code, I could see that the NETINIT_THREAD
is disabled because the IRQ pin from the PHY is not available.
It happens when the RMII configuration is set and the IRQ pin is also
used as REFCLK0.
This is also the situation with my hardwa
Hi Reto,
Just a curiosity: why are you using SDCard support over SPI?
Isn't your board prepared to use native SDCard/SDIO peripheral?
BR,
Alan
On 5/19/21, Reto Gähwiler wrote:
> Hey again,
>
> About the requested configuration of the SD-Card, here we go:
> CONFIG_MMCSD=y
> CONFIG_MMCSD_SPI
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:
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
c
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:
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 s
Hey Alan,
Thanks for your input. See reply to Jukka. About the dd command, I am aware of
and make use of it. Also the reason I could test different things with the same
image :)
Greetings, Reto
On 2021/05/18 20:53:39, Alan Carvalho de Assis wrote:
> Hi Reto,
>
> Mr. Jukka just opened a PR
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.
14 matches
Mail list logo
