Re: STM32F4 SPI DMA buffer size issue

[Oleg Evseev]

David,

I have BOARD_DMA_ALLOC_POOL_SIZE 5120 - as on other boards including
STM32F405RG based omnibus f4sd.

By the way f4sd doesn't set SPI2_DMA_BUFFER on SD card SPI2, but has
CONFIG_STM32_SPI2_DMA=y
https://github.com/PX4/PX4-Autopilot/blob/5e855c67477fe08517297a38e718ed1102536cf6/boards/omnibus/f4sd/nuttx-config/nsh/defconfig#L161

As I understand in this case NuttX SPI driver will if it is possible to do
DMA from the selected addres (CONFIG_STM32_DMACAPABLE) and probably does
not use DMA at all, right?

ср, 25 нояб. 2020 г. в 14:03, 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

[Oleg Evseev]

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

[Oleg Evseev]

> Have you scoped the interface?

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

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.

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

STM32F4 SPI DMA buffer size issue

[Oleg Evseev]

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: Serial console strange behaviour

[Oleg Evseev]

David, I've disabled CONFIG_USART6_TXDMA and it gets back to normal.
I didn't see any issue yet with other uarts that have TXDMA, only the one
with a console. Hope it is not an issue with TXDMA itself.

Would you be so kind to test smt32f7 px4 board with enabled TXDMA for
console uart please (you will need this patch to not get a hadrfault
https://github.com/apache/incubator-nuttx/pull/2209)?

ср, 11 нояб. 2020 г. в 14:18, Oleg Evseev :

> No, it is the same board and config that worked before with NuttX 8.2
> without such issues. Only several modifications same as was done for fmu-v5
> to work with 10.0.0.
> Serial consoles on PX4 boards work ok, no such issues, right?
>
> ср, 11 нояб. 2020 г. в 14:14, 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: Serial console strange behaviour

[Oleg Evseev]

No, it is the same board and config that worked before with NuttX 8.2
without such issues. Only several modifications same as was done for fmu-v5
to work with 10.0.0.
Serial consoles on PX4 boards work ok, no such issues, right?

ср, 11 нояб. 2020 г. в 14:14, 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
>

Serial console strange behaviour

[Oleg Evseev]

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: SD FAT32: Write failed with err 28 (no space left on device)

[Oleg Evseev]

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

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

[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: Telnet: up arrow key in putty returns ^[[A

[Oleg Evseev]

Hi Alan,

I can open an issue, but I can't check the latest NuttX master in the near
future, so I would like not to additionally disturb people yet :)

вс, 16 авг. 2020 г. в 17:07, Alan Carvalho de Assis :

> Hi Oleg,
>
> Well, I don't know if there is an easy way to fix it.
>
> BTW, could you please open an issue for it?
>
> https://github.com/apache/incubator-nuttx/issues
>
> BR,
>
> Alan
>
> On 8/16/20, Oleg Evseev  wrote:
> > Hi all,
> >
> > Up arrow key in Putty returns ^[[A instead of choosing last command when
> > connected to NuttX 8.2 via Telnet, while everything is ok when connected
> to
> > serial console.
> >
> > I've already tried different keyboard configurations ("linux", Xterm and
> so
> > on) in putty as suggested in internet - nothing helps.
> >
> > Windows 10, Extra putty 0.29 RC2 (I've also tried usual putty)
> >
> > Can it be NuttX issue?
> > Thanks in advance for any thoughts.
> >
> > ---
> > With regards, Oleg.
> >
>

Telnet: up arrow key in putty returns ^[[A

[Oleg Evseev]

Hi all,

Up arrow key in Putty returns ^[[A instead of choosing last command when
connected to NuttX 8.2 via Telnet, while everything is ok when connected to
serial console.

I've already tried different keyboard configurations ("linux", Xterm and so
on) in putty as suggested in internet - nothing helps.

Windows 10, Extra putty 0.29 RC2 (I've also tried usual putty)

Can it be NuttX issue?
Thanks in advance for any thoughts.

---
With regards, Oleg.

Re: stm32f7 CONFIG_RAM understanding

[Oleg Evseev]

Hi Gustavo,

You are right, this one almost surely explains the origin of these specific
numbers in config! Thanks!

ср, 5 авг. 2020 г. в 01:07, Gustavo Henrique Nihei :

> Hi Oleg,
>
> STM32F746 and STM32F769, although both being from the STM32F7 family, they
> provide different amounts of internal SRAM.
> The memory map screenshot you posted is from STM32F769.
> The screenshot below was taken from the STM32F746 datasheet. As you can
> see, the STM32F746 parts only provide 256KB of SRAM.
>
> [image: image.png]
>
> https://www.st.com/en/microcontrollers-microprocessors/stm32f746ng.html
>
> Best regards,
> Gustavo.
>
> On Tue, Aug 4, 2020 at 5:04 PM Oleg Evseev  wrote:
>
>> Hi David,
>>
>> As I see they are used to define:
>> CONFIG_RAM_END (CONFIG_RAM_START+CONFIG_RAM_SIZE)
>> which in turn is used in heap allocation (up_allocateheap).
>>
>> By the way I am working with px4 master and custom board stm32f767
>> (software very close and based on fmu-v5).
>> And I used
>> CONFIG_RAM_SIZE=376832
>> CONFIG_RAM_START=0x2002
>> but on reboots start to get random hardfaults (looking on address in log
>> points to heap allocation functions) and sometimes fails advertising uorb
>> topics (also heap allocation problem as I see).
>>
>> While I'm investigating this I notice this difference with RAM size
>> config and ask this question (of course it may not be related to my issue).
>>
>>
>> вт, 4 авг. 2020 г. в 22:49, David Sidrane :
>>
>>> Both are not used in the source. I would assume it is a legacy C from
>>> the F4, that should be removed.
>>>
>>>
>>>
>>> *From:* Oleg Evseev [mailto:ev.m...@gmail.com]
>>> *Sent:* Tuesday, August 04, 2020 12:45 PM
>>> *To:* dev@nuttx.apache.org
>>> *Subject:* Re: stm32f7 CONFIG_RAM understanding
>>>
>>>
>>>
>>> No, internal memory.
>>>
>>>
>>>
>>> For all boards
>>>
>>> stm32f769i-disco\
>>> stm32f746-ws\
>>> stm32f746g-disco\
>>> nucleo-144\
>>>
>>>
>>>
>>> but just found that except stm32f769i-disco, it understandably defines
>>> params for SRAM1 368Kb according to MCU memory map
>>>
>>> CONFIG_RAM_SIZE=376832
>>> CONFIG_RAM_START=0x2002
>>>
>>>
>>>
>>> вт, 4 авг. 2020 г. в 22:27, Gregory Nutt :
>>>
>>> External SRAM?
>>>
>>>
>>>
>>> On 8/4/2020 1:08 PM, Oleg Evseev wrote:
>>>
>>> Hi,
>>>
>>>
>>>
>>> I wonder why stm32f7 boards has such RAM parameters in defconfigs:
>>>
>>> CONFIG_RAM_SIZE=245760
>>> CONFIG_RAM_START=0x2001
>>>
>>>
>>>
>>> Where do these numbers come from while memory map is this?
>>>
>>> [image: изображение.png]
>>>
>>>
>>>
>>> ---
>>>
>>> With regards,
>>>
>>> Oleg
>>>
>>>
>>>
>>>
>
> --
> Gustavo Henrique Nihei
>

Re: stm32f7 CONFIG_RAM understanding

[Oleg Evseev]

Oh, ok. Thanks for clarification!

ср, 5 авг. 2020 г. в 01:03, David Sidrane :

> Hi Oleg,
>
>
>
> There are many up_allocateheap In the source tree…but an F7 on PX4 master
> has:
>
>
>
> And it does not use CONFIG_RAM_END (CONFIG_RAM_START+CONFIG_RAM_SIZE)
>
>
>
> I deleted them and it px4_fmuv5 still builds. I will clean that up when I
> get past the upgrade.
>
>
>
> David
>
>
>
>
>
> *From:* Oleg Evseev [mailto:ev.m...@gmail.com]
> *Sent:* Tuesday, August 04, 2020 1:04 PM
> *To:* dev@nuttx.apache.org
> *Subject:* Re: stm32f7 CONFIG_RAM understanding
>
>
>
> Hi David,
>
>
>
> As I see they are used to define:
>
> CONFIG_RAM_END (CONFIG_RAM_START+CONFIG_RAM_SIZE)
>
> which in turn is used in heap allocation (up_allocateheap).
>
>
>
> By the way I am working with px4 master and custom board stm32f767
> (software very close and based on fmu-v5).
>
> And I used
>
> CONFIG_RAM_SIZE=376832
> CONFIG_RAM_START=0x2002
>
> but on reboots start to get random hardfaults (looking on address in log
> points to heap allocation functions) and sometimes fails advertising uorb
> topics (also heap allocation problem as I see).
>
>
>
> While I'm investigating this I notice this difference with RAM size config
> and ask this question (of course it may not be related to my issue).
>
>
>
>
>
> вт, 4 авг. 2020 г. в 22:49, David Sidrane :
>
> Both are not used in the source. I would assume it is a legacy C from
> the F4, that should be removed.
>
>
>
> *From:* Oleg Evseev [mailto:ev.m...@gmail.com]
> *Sent:* Tuesday, August 04, 2020 12:45 PM
> *To:* dev@nuttx.apache.org
> *Subject:* Re: stm32f7 CONFIG_RAM understanding
>
>
>
> No, internal memory.
>
>
>
> For all boards
>
> stm32f769i-disco\
> stm32f746-ws\
> stm32f746g-disco\
> nucleo-144\
>
>
>
> but just found that except stm32f769i-disco, it understandably defines
> params for SRAM1 368Kb according to MCU memory map
>
> CONFIG_RAM_SIZE=376832
> CONFIG_RAM_START=0x2002
>
>
>
> вт, 4 авг. 2020 г. в 22:27, Gregory Nutt :
>
> External SRAM?
>
>
>
> On 8/4/2020 1:08 PM, Oleg Evseev wrote:
>
> Hi,
>
>
>
> I wonder why stm32f7 boards has such RAM parameters in defconfigs:
>
> CONFIG_RAM_SIZE=245760
> CONFIG_RAM_START=0x2001
>
>
>
> Where do these numbers come from while memory map is this?
>
> [image: изображение.png]
>
>
>
> ---
>
> With regards,
>
> Oleg
>
>
>
>

Re: stm32f7 CONFIG_RAM understanding

[Oleg Evseev]

Hi David,

As I see they are used to define:
CONFIG_RAM_END (CONFIG_RAM_START+CONFIG_RAM_SIZE)
which in turn is used in heap allocation (up_allocateheap).

By the way I am working with px4 master and custom board stm32f767
(software very close and based on fmu-v5).
And I used
CONFIG_RAM_SIZE=376832
CONFIG_RAM_START=0x2002
but on reboots start to get random hardfaults (looking on address in log
points to heap allocation functions) and sometimes fails advertising uorb
topics (also heap allocation problem as I see).

While I'm investigating this I notice this difference with RAM size config
and ask this question (of course it may not be related to my issue).


вт, 4 авг. 2020 г. в 22:49, David Sidrane :

> Both are not used in the source. I would assume it is a legacy C from
> the F4, that should be removed.
>
>
>
> *From:* Oleg Evseev [mailto:ev.m...@gmail.com]
> *Sent:* Tuesday, August 04, 2020 12:45 PM
> *To:* dev@nuttx.apache.org
> *Subject:* Re: stm32f7 CONFIG_RAM understanding
>
>
>
> No, internal memory.
>
>
>
> For all boards
>
> stm32f769i-disco\
> stm32f746-ws\
> stm32f746g-disco\
> nucleo-144\
>
>
>
> but just found that except stm32f769i-disco, it understandably defines
> params for SRAM1 368Kb according to MCU memory map
>
> CONFIG_RAM_SIZE=376832
> CONFIG_RAM_START=0x2002
>
>
>
> вт, 4 авг. 2020 г. в 22:27, Gregory Nutt :
>
> External SRAM?
>
>
>
> On 8/4/2020 1:08 PM, Oleg Evseev wrote:
>
> Hi,
>
>
>
> I wonder why stm32f7 boards has such RAM parameters in defconfigs:
>
> CONFIG_RAM_SIZE=245760
> CONFIG_RAM_START=0x2001
>
>
>
> Where do these numbers come from while memory map is this?
>
> [image: изображение.png]
>
>
>
> ---
>
> With regards,
>
> Oleg
>
>
>
>

Re: stm32f7 CONFIG_RAM understanding

[Oleg Evseev]

No, internal memory.

For all boards
stm32f769i-disco\
stm32f746-ws\
stm32f746g-disco\
nucleo-144\

but just found that except stm32f769i-disco, it understandably defines
params for SRAM1 368Kb according to MCU memory map
CONFIG_RAM_SIZE=376832
CONFIG_RAM_START=0x2002

вт, 4 авг. 2020 г. в 22:27, Gregory Nutt :

> External SRAM?
>
> On 8/4/2020 1:08 PM, Oleg Evseev wrote:
>
> Hi,
>
> I wonder why stm32f7 boards has such RAM parameters in defconfigs:
> CONFIG_RAM_SIZE=245760
> CONFIG_RAM_START=0x2001
>
> Where do these numbers come from while memory map is this?
> [image: изображение.png]
>
> ---
> With regards,
> Oleg
>
>
>

stm32f7 CONFIG_RAM understanding

[Oleg Evseev]

Hi,

I wonder why stm32f7 boards has such RAM parameters in defconfigs:
CONFIG_RAM_SIZE=245760
CONFIG_RAM_START=0x2001

Where do these numbers come from while memory map is this?
[image: изображение.png]

---
With regards,
Oleg

Re: stm32f7 CAN driver

[Oleg Evseev]

Found out that our issues were caused just by bad timings. Default ones
fitted stm32f4 168 MHz, but were not good for stm32f7 216 MHz.

For some reason I wrongly thought that NuttX CAN driver calculate best
Phase_Seg1 and Phase_Seg2 itself, like for example it is done in libuavcan
https://github.com/PX4/libuavcan/blob/52e7ce09907bcec8a0b93e7a15d5fbd121c686dc/libuavcan_drivers/stm32/driver/src/uc_stm32_can.cpp#L195

ср, 22 июл. 2020 г. в 11:29, Oleg Evseev :

> Hi Ben,
>
> Yes, I mean native internal stm32f7 CAN controller RX, TX connected to CAN
> phy chip (SN65HVD230 in our case).
> We have no problems with stm32f4, but can't get it working with stm32f7
> yet - mcu sends something to TX, but CAN analyzers do not see any messages
> on CAN bus.
>
> ср, 22 июл. 2020 г. в 10:54, Disruptive Solutions <
> disruptivesolution...@gmail.com>:
>
>> Oleg do you mean the SPI version (mcp) or native with a say tja1050? The
>> SPI version I use on different platforms. The stm32f7 I have to try
>> though...
>>
>> Ben
>>
>> Op di 21 jul. 2020 23:06 schreef Oleg Evseev :
>>
>> > Hi all,
>> >
>> > Did anybody use the NuttX CAN driver with stm32f7 mcu? Does it work ok?
>> >
>> > ---
>> > With regards, Oleg.
>> >
>>
>

Re: stm32f7 CAN driver

[Oleg Evseev]

Hi Ben,

Yes, I mean native internal stm32f7 CAN controller RX, TX connected to CAN
phy chip (SN65HVD230 in our case).
We have no problems with stm32f4, but can't get it working with stm32f7 yet
- mcu sends something to TX, but CAN analyzers do not see any messages on
CAN bus.

ср, 22 июл. 2020 г. в 10:54, Disruptive Solutions <
disruptivesolution...@gmail.com>:

> Oleg do you mean the SPI version (mcp) or native with a say tja1050? The
> SPI version I use on different platforms. The stm32f7 I have to try
> though...
>
> Ben
>
> Op di 21 jul. 2020 23:06 schreef Oleg Evseev :
>
> > Hi all,
> >
> > Did anybody use the NuttX CAN driver with stm32f7 mcu? Does it work ok?
> >
> > ---
> > With regards, Oleg.
> >
>

stm32f7 CAN driver

[Oleg Evseev]

Hi all,

Did anybody use the NuttX CAN driver with stm32f7 mcu? Does it work ok?

---
With regards, Oleg.

Re: How to debug DEBUGASSERT in shed?

[Oleg Evseev]

 Found out that DEBUGASSERT(pholder != NULL) was not caused by can driver
itself, but just related to a task, where I'm polling can, that's why I
misled, sorry.
Alan and Gregory, thanks for feedbacks!

As for issue 1354 <https://github.com/apache/incubator-nuttx/issues/1354>,
made the PR 1370 <https://github.com/apache/incubator-nuttx/pull/1370>.

пт, 3 июл. 2020 г. в 16:26, Oleg Evseev :

> Hi, Alan.
>
> Thanks for the feedback.
>
> Found out that I'm still get DEBUGASSERT(pholder != NULL) in function
> nxsem_allocholder in file semaphore/sem_holder.c after
> DEBUGASSERT(sem->semcount related.
> I'm trying to investigate this.
>
> пт, 3 июл. 2020 г. в 15:47, Alan Carvalho de Assis :
>
>> Hi Oleg,
>>
>> I just responded your issue.
>>
>> I hope to have shed some light there.
>>
>> BR,
>>
>> Alan
>>
>> On 7/3/20, Oleg Evseev  wrote:
>> > Regarding to can driver, from some moment I started getting
>> > DEBUGASSERT(sem->semcount> > in sem_post.c. Found the bug
>> > https://github.com/apache/incubator-nuttx/issues/1354
>> >
>> > I don't know, was DEBUGASSERT(pholder != NULL) a different appearance of
>> > the same bug or it is something else.
>> >
>> > --
>> > With regards,
>> > Oleg.
>> >
>> >
>> > вт, 30 июн. 2020 г. в 20:16, Oleg Evseev :
>> >
>> >> Find out that this happens while in poll.
>> >>
>> >> вт, 30 июн. 2020 г. в 15:45, Oleg Evseev :
>> >>
>> >>> Hi all,
>> >>>
>> >>> I wonder how can I debug
>> >>> DEBUGASSERT(pholder != NULL) in function nxsem_allocholder in file
>> >>> semaphore/sem_holder.c that happens after some time reading a lot of
>> >>> messages from can bus in can_reciever task?
>> >>>
>> >>> Task  looks like this (CAN dev is opened as shared file with
>> >>> file_open(>file, "/dev/can0", O_RDWR)):
>> >>>
>> >>> pollfd fds[1];
>> >>> fds[0].fd = -1;
>> >>> fds[0].ptr = CANmodule->file ;
>> >>> fds[0].events = POLLIN | POLLFILE;
>> >>>
>> >>> while (!_thread_should_exit) {
>> >>> int ret = poll(fds, sizeof(fds) / sizeof(fds[0]), 1000);
>> >>>
>> >>> if (fds[0].revents & POLLIN) {
>> >>> /* Read the RX message */
>> >>> CANreceive();
>> >>> }
>> >>> }
>> >>>
>> >>> void CANreceive(CANmodule_t *CANmodule){
>> >>> struct can_msg_s msg = {};
>> >>> ssize_t nbytes;
>> >>>
>> >>> nbytes = file_read(>file, ,  sizeof(struct
>> can_msg_s)
>> >>> );
>> >>> ...
>> >>> }
>> >>>
>> >>> Thanks in advance for any help.
>> >>>
>> >>> --
>> >>> With regards,
>> >>> Oleg.
>> >>>
>> >>
>> >
>>
>

Re: How to debug DEBUGASSERT in shed?

[Oleg Evseev]

Hi, Alan.

Thanks for the feedback.

Found out that I'm still get DEBUGASSERT(pholder != NULL) in function
nxsem_allocholder in file semaphore/sem_holder.c after
DEBUGASSERT(sem->semcount:

> Hi Oleg,
>
> I just responded your issue.
>
> I hope to have shed some light there.
>
> BR,
>
> Alan
>
> On 7/3/20, Oleg Evseev  wrote:
> > Regarding to can driver, from some moment I started getting
> > DEBUGASSERT(sem->semcount > in sem_post.c. Found the bug
> > https://github.com/apache/incubator-nuttx/issues/1354
> >
> > I don't know, was DEBUGASSERT(pholder != NULL) a different appearance of
> > the same bug or it is something else.
> >
> > --
> > With regards,
> > Oleg.
> >
> >
> > вт, 30 июн. 2020 г. в 20:16, Oleg Evseev :
> >
> >> Find out that this happens while in poll.
> >>
> >> вт, 30 июн. 2020 г. в 15:45, Oleg Evseev :
> >>
> >>> Hi all,
> >>>
> >>> I wonder how can I debug
> >>> DEBUGASSERT(pholder != NULL) in function nxsem_allocholder in file
> >>> semaphore/sem_holder.c that happens after some time reading a lot of
> >>> messages from can bus in can_reciever task?
> >>>
> >>> Task  looks like this (CAN dev is opened as shared file with
> >>> file_open(>file, "/dev/can0", O_RDWR)):
> >>>
> >>> pollfd fds[1];
> >>> fds[0].fd = -1;
> >>> fds[0].ptr = CANmodule->file ;
> >>> fds[0].events = POLLIN | POLLFILE;
> >>>
> >>> while (!_thread_should_exit) {
> >>> int ret = poll(fds, sizeof(fds) / sizeof(fds[0]), 1000);
> >>>
> >>> if (fds[0].revents & POLLIN) {
> >>> /* Read the RX message */
> >>> CANreceive();
> >>> }
> >>> }
> >>>
> >>> void CANreceive(CANmodule_t *CANmodule){
> >>> struct can_msg_s msg = {};
> >>> ssize_t nbytes;
> >>>
> >>> nbytes = file_read(>file, ,  sizeof(struct
> can_msg_s)
> >>> );
> >>> ...
> >>> }
> >>>
> >>> Thanks in advance for any help.
> >>>
> >>> --
> >>> With regards,
> >>> Oleg.
> >>>
> >>
> >
>

Re: How to debug DEBUGASSERT in shed?

[Oleg Evseev]

Regarding to can driver, from some moment I started getting
DEBUGASSERT(sem->semcounthttps://github.com/apache/incubator-nuttx/issues/1354

I don't know, was DEBUGASSERT(pholder != NULL) a different appearance of
the same bug or it is something else.

-- 
With regards,
Oleg.


вт, 30 июн. 2020 г. в 20:16, Oleg Evseev :

> Find out that this happens while in poll.
>
> вт, 30 июн. 2020 г. в 15:45, Oleg Evseev :
>
>> Hi all,
>>
>> I wonder how can I debug
>> DEBUGASSERT(pholder != NULL) in function nxsem_allocholder in file
>> semaphore/sem_holder.c that happens after some time reading a lot of
>> messages from can bus in can_reciever task?
>>
>> Task  looks like this (CAN dev is opened as shared file with
>> file_open(>file, "/dev/can0", O_RDWR)):
>>
>> pollfd fds[1];
>> fds[0].fd = -1;
>> fds[0].ptr = CANmodule->file ;
>> fds[0].events = POLLIN | POLLFILE;
>>
>> while (!_thread_should_exit) {
>> int ret = poll(fds, sizeof(fds) / sizeof(fds[0]), 1000);
>>
>> if (fds[0].revents & POLLIN) {
>> /* Read the RX message */
>> CANreceive();
>> }
>> }
>>
>> void CANreceive(CANmodule_t *CANmodule){
>> struct can_msg_s msg = {};
>> ssize_t nbytes;
>>
>> nbytes = file_read(>file, ,  sizeof(struct can_msg_s)
>> );
>> ...
>> }
>>
>> Thanks in advance for any help.
>>
>> --
>> With regards,
>> Oleg.
>>
>

CAN driver and critical section use

[Oleg Evseev]

Hi all,

I wonder if it is right to call nxsem_wait while in critical section?

Regardless of the answer I also wonder why can_read() and can_write()
enter_critical_section before accessing the received FIFO, but can_poll
doesn't?

Can this be related to getting into DEBUGASSERT(pholder != NULL) in
function nxsem_allocholder in file semaphore/sem_holder.c while in poll on
can?

-- 
With regards, Oleg.

Re: How to debug DEBUGASSERT in shed?

[Oleg Evseev]

Find out that this happens while in poll.

вт, 30 июн. 2020 г. в 15:45, Oleg Evseev :

> Hi all,
>
> I wonder how can I debug
> DEBUGASSERT(pholder != NULL) in function nxsem_allocholder in file
> semaphore/sem_holder.c that happens after some time reading a lot of
> messages from can bus in can_reciever task?
>
> Task  looks like this (CAN dev is opened as shared file with
> file_open(>file, "/dev/can0", O_RDWR)):
>
> pollfd fds[1];
> fds[0].fd = -1;
> fds[0].ptr = CANmodule->file ;
> fds[0].events = POLLIN | POLLFILE;
>
> while (!_thread_should_exit) {
> int ret = poll(fds, sizeof(fds) / sizeof(fds[0]), 1000);
>
> if (fds[0].revents & POLLIN) {
> /* Read the RX message */
> CANreceive();
> }
> }
>
> void CANreceive(CANmodule_t *CANmodule){
> struct can_msg_s msg = {};
> ssize_t nbytes;
>
> nbytes = file_read(>file, ,  sizeof(struct can_msg_s) );
> ...
> }
>
> Thanks in advance for any help.
>
> --
> With regards,
> Oleg.
>


-- 
С Уважением,
Евсеев Олег.

How to debug DEBUGASSERT in shed?

[Oleg Evseev]

Hi all,

I wonder how can I debug
DEBUGASSERT(pholder != NULL) in function nxsem_allocholder in file
semaphore/sem_holder.c that happens after some time reading a lot of
messages from can bus in can_reciever task?

Task  looks like this (CAN dev is opened as shared file with
file_open(>file, "/dev/can0", O_RDWR)):

pollfd fds[1];
fds[0].fd = -1;
fds[0].ptr = CANmodule->file ;
fds[0].events = POLLIN | POLLFILE;

while (!_thread_should_exit) {
int ret = poll(fds, sizeof(fds) / sizeof(fds[0]), 1000);

if (fds[0].revents & POLLIN) {
/* Read the RX message */
CANreceive();
}
}

void CANreceive(CANmodule_t *CANmodule){
struct can_msg_s msg = {};
ssize_t nbytes;

nbytes = file_read(>file, ,  sizeof(struct can_msg_s) );
...
}

Thanks in advance for any help.

-- 
With regards,
Oleg.

Re: Get size of block character device file with stat()

[Oleg Evseev]

 > The bch driver supports an IOCTL called BIOC_GEOMETRY that will return
the geometry of the underlying block device.

Yes, I understand. But user application handle all files the same way using
path and
int stat(FAR const char *path, FAR struct stat *buf) function.

I've made a pull request #1118

Patch doesn't do the trick for bch driver of course, but at least for block
drivers.
Merge or drop it as you wish, if it is not appropriate.

пн, 25 мая 2020 г. в 17:40, Gregory Nutt :

>
> > It looks like I overthink and the best and simple solution is just to use
> > for all block devices the block_operation function of inode to get
> geometry:
> > inode->u.i_bops->geometry
> >
> > I miss that bchlib is already use this function to fill bchlib_s
> structure.
> >
> > Will try this approach now.
> The bch driver supports an IOCTL called BIOC_GEOMETRY that will return
> the geometry of the underlying block device.
>

Re: Get size of block character device file with stat()

[Oleg Evseev]

It looks like I overthink and the best and simple solution is just to use
for all block devices the block_operation function of inode to get geometry:
   inode->u.i_bops->geometry

I miss that bchlib is already use this function to fill bchlib_s structure.

Will try this approach now.

пн, 25 мая 2020 г. в 15:03, Oleg Evseev :

> Hi,
>
> I wonder how to get size of character device that referenced mtd partition
> block device? As I see bchlib_setup in drivers/bch/bchlib_setup.c fills
> block geometry info to bchlib_s structure (number of sectors and sector
> size) that then stored as i_private to inode.
>
> This inode is part of the root pseudo file system and when user call
> stat() code leads to inode_stat function in fs/vfs/fs_stat.c that fills
> only file attributes info (st_mode).
>
> I suppose here inode_stat also could fill size of file in bytes (st_size)
> based on geometry from i_private bchlib_s structure.
>
> But how to correctly determine that device is BCH here, to be sure that
> casting to bchlib_s will be correct? INODE_IS_BLOCK(inode) is obviously not
> enough criteria.
>
> I'm not good in inode stuff, so maybe this is stupid idea, but could I
> check file_operations functions pointers to be equal to certain functions
> of BCH? Something like:
> if (inode->u.i_ops->read == bch_read) {}
>
> Anyway it would be done, fs_stat will be depended on BCH driver. But I
> suppose it is not right, is it?
>
> p.s. also I suppose same thing is related to block devices themselves,
> they could provide geometry info to determine file size for stat().
>
> Thanks for any thoughts!
>
> --
> With regards, Oleg.
>

Get size of block character device file with stat()

[Oleg Evseev]

Hi,

I wonder how to get size of character device that referenced mtd partition
block device? As I see bchlib_setup in drivers/bch/bchlib_setup.c fills
block geometry info to bchlib_s structure (number of sectors and sector
size) that then stored as i_private to inode.

This inode is part of the root pseudo file system and when user call stat()
code leads to inode_stat function in fs/vfs/fs_stat.c that fills only file
attributes info (st_mode).

I suppose here inode_stat also could fill size of file in bytes (st_size)
based on geometry from i_private bchlib_s structure.

But how to correctly determine that device is BCH here, to be sure that
casting to bchlib_s will be correct? INODE_IS_BLOCK(inode) is obviously not
enough criteria.

I'm not good in inode stuff, so maybe this is stupid idea, but could I
check file_operations functions pointers to be equal to certain functions
of BCH? Something like:
if (inode->u.i_ops->read == bch_read) {}

Anyway it would be done, fs_stat will be depended on BCH driver. But I
suppose it is not right, is it?

p.s. also I suppose same thing is related to block devices themselves, they
could provide geometry info to determine file size for stat().

Thanks for any thoughts!

-- 
With regards, Oleg.

Re: [PATCH] apps, system/cu fix and additional option

[Oleg Evseev]

Ok, thanks!

сб, 14 мар. 2020 г. в 01:08, Abdelatif Guettouche <
abdelatif.guettou...@gmail.com>:

> Hi,
>
> Thanks. I created a PR based on your patches
> (https://github.com/apache/incubator-nuttx-apps/pull/122)
> Github PRs pass through the CI checks and make the review process smother.
> If you can use Github, please for future contributions submit PRs at
> https://github.com/apache/incubator-nuttx and
> https://github.com/apache/incubator-nuttx-apps
>
> Thanks.
>
> On Fri, Mar 13, 2020 at 9:41 PM Oleg Evseev  wrote:
> >
> > Hi,
> >
> > Resend txts
> >
> > сб, 14 мар. 2020 г. в 00:31, Abdelatif Guettouche <
> abdelatif.guettou...@gmail.com>:
> >>
> >> Hi Oleg,
> >>
> >> Unfortunately the patch didn't make it through.
> >> Could you please resend it again with a .txt extension or open a PR in
> >> https://github.com/apache/incubator-nuttx-apps
> >>
> >> On Fri, Mar 13, 2020 at 3:26 PM Oleg Evseev  wrote:
> >> >
> >> > 1) system/cu: fix wrongly swapped parity options
> >> > 2) system/cu: add option -f to loop forever
> >> > endless mode: pass all characters and ignore escape sequence, handy
> to interact with serial devices with binary protocol
> >> >
> >> > --
> >> > Best Regards,
> >> > Oleg
>

Re: [PATCH] apps, system/cu fix and additional option

[Oleg Evseev]

Hi,

Resend txts

сб, 14 мар. 2020 г. в 00:31, Abdelatif Guettouche <
abdelatif.guettou...@gmail.com>:

> Hi Oleg,
>
> Unfortunately the patch didn't make it through.
> Could you please resend it again with a .txt extension or open a PR in
> https://github.com/apache/incubator-nuttx-apps
>
> On Fri, Mar 13, 2020 at 3:26 PM Oleg Evseev  wrote:
> >
> > 1) system/cu: fix wrongly swapped parity options
> > 2) system/cu: add option -f to loop forever
> > endless mode: pass all characters and ignore escape sequence, handy to
> interact with serial devices with binary protocol
> >
> > --
> > Best Regards,
> > Oleg
>
From afdd750fdc404600b2f28811d24474568ef3aadc Mon Sep 17 00:00:00 2001
From: Oleg Evseev 
Date: Fri, 13 Mar 2020 18:18:55 +0300
Subject: [PATCH] system/cu: add option -f to loop forever

endless mode: pass all characters and ignore escape sequence, handy to interact 
with serial devices with binary protocol
---
 system/cu/cu_main.c | 14 +-
 1 file changed, 13 insertions(+), 1 deletion(-)

diff --git a/system/cu/cu_main.c b/system/cu/cu_main.c
index 2c91d427..4e59ad4c 100644
--- a/system/cu/cu_main.c
+++ b/system/cu/cu_main.c
@@ -225,6 +225,7 @@ static void print_help(void)
  " -o: Set odd parity\n"
  " -s: Use given speed (default %d)\n"
  " -r: Disable RTS/CTS flow control (default: on)\n"
+ " -f: Enable endless mode without escape sequence (default: off)\n"
  " -?: This help\n",
  CONFIG_SYSTEM_CUTERM_DEFAULT_DEVICE,
  CONFIG_SYSTEM_CUTERM_DEFAULT_BAUD);
@@ -274,6 +275,7 @@ int main(int argc, FAR char *argv[])
   int baudrate = CONFIG_SYSTEM_CUTERM_DEFAULT_BAUD;
   enum parity_mode parity = PARITY_NONE;
   int rtscts = 1;
+  int nobreak = 0;
   int option;
   int ret;
   int bcmd;
@@ -291,7 +293,7 @@ int main(int argc, FAR char *argv[])
   sigaction(SIGKILL, , NULL);
 
   optind = 0;   /* global that needs to be reset in FLAT mode */
-  while ((option = getopt(argc, argv, "l:s:ehor?")) != ERROR)
+  while ((option = getopt(argc, argv, "l:s:efhor?")) != ERROR)
 {
   switch (option)
 {
@@ -315,6 +317,10 @@ int main(int argc, FAR char *argv[])
 rtscts = 0;
 break;
 
+  case 'f':
+  nobreak = 1;
+  break;
+
   case 'h':
   case '?':
 print_help();
@@ -377,6 +383,12 @@ int main(int argc, FAR char *argv[])
 {
   int ch = getc(stdin);
 
+  if (nobreak == 1)
+{
+  write(g_cu.outfd, , 1);
+  continue;
+}
+
   if (ch <= 0)
 {
   continue;
-- 
2.24.0.windows.2

From 5a38efdd00455a1ed40a805ea909803d983a35cf Mon Sep 17 00:00:00 2001
From: Oleg Evseev 
Date: Fri, 13 Mar 2020 18:11:43 +0300
Subject: [PATCH] system/cu: fix wrongly swapped parity options

---
 system/cu/cu_main.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/system/cu/cu_main.c b/system/cu/cu_main.c
index 5311ffc3..2c91d427 100644
--- a/system/cu/cu_main.c
+++ b/system/cu/cu_main.c
@@ -304,11 +304,11 @@ int main(int argc, FAR char *argv[])
 break;
 
   case 'e':
-parity = PARITY_ODD;
+parity = PARITY_EVEN;
 break;
 
   case 'o':
-parity = PARITY_EVEN;
+parity = PARITY_ODD;
 break;
 
   case 'r':
-- 
2.24.0.windows.2

Re: Usrsocktest app example fails

[Oleg Evseev]

 Hi Xiang,

I've checked https://github.com/apache/incubator-nuttx/pull/354 PR. It
fixed issues it supposed to fix, thanks.

But I've still have semaphore assertion running test case
WakeBlockingConnectMultiThread
in do_wake_test() on third call in loop of sem_post(_releasesem) when
tidx is 2.
(examples/usrsocktest/usrsocktest_wake_with_signal.c:515)
[image: изображение.png]

As I understand, you do not have such issue, so it's looks like reason is
totally somewhere in my configuration.
Especially due to fact that, as I wrote, I'm playing with it on Windows
inside px4 project on my custom board with stm32f405, using latest original
nuttx and apps.

I had tried to increase twice CONFIG_EXAMPLES_USRSOCKTEST_STACKSIZE, it
didn't help, assertion in the same place.

сб, 22 февр. 2020 г. в 18:11, Xiang Xiao :

> The semaphore assertion look like the memory corrruption(maybe the
> stack too small) which platform you are running.
>
> On Sat, Feb 22, 2020 at 6:52 PM Oleg Evseev  wrote:
> >
> > Hi Xiang,
> >
> > I can check it only on Monday, thanks!
> >
> > But, by the way, in commits you mentioned several errors in usrsocktest
> > that looks different than on my first screenshot (especially debug
> > assertion failed somewhere inside semaphore). Maybe there will still be
> > problems due to my wrong settings. Will see after checking this PR.
> > In any case, thanks for your time and support!
> >
> > сб, 22 февр. 2020 г. в 13:38, Xiang Xiao :
> >
> > > Oleg, try this PR:
> > > https://github.com/apache/incubator-nuttx/pull/354
> > > with Masayuki and my patch, all test in usrsocktest should pass now.
> > > Actually, all fail is very minor:
> > > 1.Set the different errno
> > > 2.Foget to check NULL pointer
> > > 3.Don't zero the sockaddr padding bytes
> > > ,usrsock work well very even without these patch.
>

Re: Usrsocktest app example fails

[Oleg Evseev]

Hi Xiang,

I can check it only on Monday, thanks!

But, by the way, in commits you mentioned several errors in usrsocktest
that looks different than on my first screenshot (especially debug
assertion failed somewhere inside semaphore). Maybe there will still be
problems due to my wrong settings. Will see after checking this PR.
In any case, thanks for your time and support!

сб, 22 февр. 2020 г. в 13:38, Xiang Xiao :

> Oleg, try this PR:
> https://github.com/apache/incubator-nuttx/pull/354
> with Masayuki and my patch, all test in usrsocktest should pass now.
> Actually, all fail is very minor:
> 1.Set the different errno
> 2.Foget to check NULL pointer
> 3.Don't zero the sockaddr padding bytes
> ,usrsock work well very even without these patch.
>
> On Fri, Feb 21, 2020 at 4:17 PM Oleg Evseev  wrote:
> >
> > Hi Masayuki,
> >
> > Thanks for the work! Looking forward to new PRs.
> >
> > пт, 21 февр. 2020 г. в 08:42, Ishikawa, Masayuki (SHES) <
> > masayuki.ishik...@sony.com>:
> >
> > > Hi, Oleg,
> > >
> > >
> > >
> > > Though I am not an author of the code,
> > >
> > > I found a couple of bugs both usrsocktest and nuttx.
> > >
> > > I will send PRs later.
> > >
> > >
> > >
> > > Regards,
> > >
> > > Masayuki
> > >
> > >
> > >
> > >
>

Re: Usrsocktest app example fails

[Oleg Evseev]

Turned on DEBUG_ASSERTIONS, DEBUG_NET_ERROR=y, DEBUG_NET_INFO=y,
DEBUG_NET_WARN=y, left only WakeWithSignal test in usrsocktest example, got
hardfault in debug assertion somewhere in semaphores

nsh> Starting unit-tests...
Testing group "WakeWithSignal" =>
usrsockdev_open: opening /dev/usrsock
usrsockdev_pollnotify: Report events: 01
usrsock_event: events: 8000
socket_event: request completed.
usrsockdev_pollnotify: Report events: 01
usrsockdev_close: closing /dev/usrsock
usrsock_event: events: 0002
connect_event: socket aborted.
usrsock_close: usockid=1; already closed.
usrsockdev_open: opening /dev/usrsock
usrsockdev_pollnotify: Report events: 01
usrsock_event: events: 8000
socket_event: request completed.
usrsockdev_pollnotify: Report events: 01
usrsock_event: events: 8000
socket_event: request completed.
usrsockdev_pollnotify: Report events: 01
usrsock_event: events: 8000
socket_event: request completed.
usrsockdev_pollnotify: Report events: 01
usrsock_event: events: 8000
socket_evenup_assert: Assertion failed at file:semaphore/sem_holder.c line:
128 task: usrsocktest

on attempt blocking connect
do_usrsock_blocking_close_thread:
  /* Attempt blocking connect. */
  ret = connect(test_sd[tidx], (FAR const struct sockaddr *),
sizeof(addr));
-> usrsock_connect:
  /* Wait for completion of request (or signal). */
  ret = net_lockedwait();


чт, 20 февр. 2020 г. в 13:19, Oleg Evseev :

> Hi all,
>
> Trying to run usrsocktest example from app:
> [image: изображение.png]
>
> 1) first two failed test in NoBlockRecv and BlockRecv fail because
> ret = recvfrom(sd, data, datalen, 0, (FAR struct sockaddr
> *), );
> fills sin_zero in remoteaddr with some notzero values.
>
> [image: изображение.png]
> 2) BasicGetSockName fails because usrsock_getsockname doesn't check addr
> for not null, so test with NULL addr do not get expected error.
>
> 3) WakeWithSignal after this fails hangs up the app.
>
> I'm not blaming anyone and do not complain, please do not be offended.
> Thanks for all this work, really, but I'm in deep wonder does anybody run
> this example at least once before? I thought that usrsock is quite stable
> and I would like to concentrate on cell modem driver development and not
> the net/usrsock stack itself in which I have very little knowledge.
> I'm still thinking that I've set something wrong, especially due to fact
> that I'm playing with it through px4 project in fact (but using latest
> original Nuttx).
>
> Thanks for any thoughts.
>
> --
> With regards, Oleg.
>

Usrsocktest app example fails

[Oleg Evseev]

Hi all,

Trying to run usrsocktest example from app:
[image: изображение.png]

1) first two failed test in NoBlockRecv and BlockRecv fail because
ret = recvfrom(sd, data, datalen, 0, (FAR struct sockaddr
*), );
fills sin_zero in remoteaddr with some notzero values.

[image: изображение.png]
2) BasicGetSockName fails because usrsock_getsockname doesn't check addr
for not null, so test with NULL addr do not get expected error.

3) WakeWithSignal after this fails hangs up the app.

I'm not blaming anyone and do not complain, please do not be offended.
Thanks for all this work, really, but I'm in deep wonder does anybody run
this example at least once before? I thought that usrsock is quite stable
and I would like to concentrate on cell modem driver development and not
the net/usrsock stack itself in which I have very little knowledge.
I'm still thinking that I've set something wrong, especially due to fact
that I'm playing with it through px4 project in fact (but using latest
original Nuttx).

Thanks for any thoughts.

-- 
With regards, Oleg.

Re: Can't make work shared file for CAN

[Oleg Evseev]

Hi!

Is it really matters? I think the issue is more about file descriptors,
file pointers and so on.
CAN is configured with extended ID. Yes, I did use CAN app from examples,
it works.
Implementation in my own app also works fine if I use file descriptor when
opened /dev/can0. In different threads of one  task group - no problems.

Now I want to also send messages from another thread from different task
group, but  file descriptors cannot be used by different tasks. So I'm
trying to use internal OS interface from
https://www.nuttx.org/doku.php?id=wiki:nxinternal:detachedfds

But file_read on file pointer doesn't work in the same way as read on file
descriptor, even if it is in the same thread - right after file_open!

чт, 16 янв. 2020 г. в 00:11, Disruptive Solutions <
disruptivesolution...@gmail.com>:

> Oleg: do you use an extended ID or standard ID? And do you use the CAN app
> from examples?
>
> Verstuurd vanaf mijn iPhone
>
> > Op 15 jan. 2020 om 22:02 heeft Oleg Evseev  het
> volgende geschreven:
> >
> > Hi!
> >
> > When I use usual file descriptor for can device:
> > file_open(>file, "/dev/can0", O_RDWR);
> > everything works, thread blocks if further read() and, when can message
> > receive, returns correct nbytes.
> >
> > When I open can0 with
> > file_open(, "/dev/can0", O_RDWR);
> >
> > it opens correctly and file_ioctl seems to work. But file_read from 
> > do not block and return immediately same nbytes as requested with some
> > garbage in data. But there is no data on CAN bus. Polling (of course with
> > POLLFILE mask) also do not get blocked and return POLLIN event
> immediately.
> >
> > Doing file_detach() as describe in
> > https://www.nuttx.org/doku.php?id=wiki:nxinternal:detachedfds leads to
> the
> > same result.
> >
> > Any thoughts?
> >
> > Thanks.
> >
> > --
> > With regards,
> > Oleg Evseev
>

Can't make work shared file for CAN

[Oleg Evseev]

Hi!

When I use usual file descriptor for can device:
file_open(>file, "/dev/can0", O_RDWR);
everything works, thread blocks if further read() and, when can message
receive, returns correct nbytes.

When I open can0 with
file_open(, "/dev/can0", O_RDWR);

it opens correctly and file_ioctl seems to work. But file_read from 
do not block and return immediately same nbytes as requested with some
garbage in data. But there is no data on CAN bus. Polling (of course with
POLLFILE mask) also do not get blocked and return POLLIN event immediately.

Doing file_detach() as describe in
https://www.nuttx.org/doku.php?id=wiki:nxinternal:detachedfds leads to the
same result.

Any thoughts?

Thanks.

--
With regards,
Oleg Evseev