Re: QSPI on STM32F7
hi Rob, I have a problem similar to yours,i have configured “QPSI” with interrupt mode,but It's not working. i can get the RDID and memory capacity via QSPI,but there is incorrect data(0x88) read back after execute the chip erase command. could hepe me? Rob Voisey 于2020年5月5日周二 下午11:09写道： > Actually it was my fault, I'm on a slightly old build and although I'd > diffed stm32_qspi.c against the head I'd missed an actual fix amongst all > the formatting corrections. I did a more thorough job this time and my > MX23L51245G driver now appears to read, write and erase correctly. > > I'm still interested in João's patches in case there are other issues I > haven't run into yet. > > Cheers > > Rob > > On Tue, 5 May 2020 at 13:33, Rob Voisey wrote: > > > Hi João, > > > > Thanks, I'd love to get those patches if you could email or commit them. > > > > Right now, using the MTD interface, I can read blocks of data but I can't > > erase them because that uses a non-data command and those never set TCF > for > > reasons I've yet to understand. > > > > Rob > > > > On Tue, 5 May 2020 at 13:11, Joao Matos wrote: > > > >> Hello Rob, > >> > >> We have been using the STM32 F7 QSPI code, and found out the same > issues. > >> > >> I've attached some patches with the fixes we have made, hope that helps. > >> > >> > >> > >> On Mon, May 4, 2020 at 7:18 PM Rob Voisey > wrote: > >> > >>> Thanks Alan. I see it's almost an identical driver so I'll see if I can > >>> get > >>> hold of an L4 board. > >>> > >>> Rob > >>> > >>> > >>> On Mon, 4 May 2020 at 19:05, Alan Carvalho de Assis > > >>> wrote: > >>> > >>> > Hi Rob, > >>> > > >>> > There are some QSPI usage examples for STM32L4 that is very similar > >>> > and you can use as starting point. > >>> > > >>> > BR, > >>> > > >>> > Alan > >>> > > >>> > On 5/4/20, Rob Voisey wrote: > >>> > > Hi > >>> > > > >>> > > I haven't been able to find any code that uses the STM32F7 QSPI > code > >>> even > >>> > > though it has been in the codebase for a few years. An example > >>> candidate > >>> > > would be the STM32F769I-DISC0 board which has an MX25L51245G flash > >>> device > >>> > > on that bus. It's also the combination that I need to get working > >>> for my > >>> > > board. > >>> > > > >>> > > To that end I wrote a driver for the MX25L51245G forked from the > >>> existing > >>> > > MX25RXX driver, and I'm having some trouble getting non-data > >>> commands to > >>> > > complete. The RDID command works fine but non-data commands hang in > >>> the > >>> > > QSPI driver waiting on transfer complete status. I've spent a few > >>> hours > >>> > > poking around but to narrow it down I was wondering if anyone knows > >>> the > >>> > > status of the F7 QSPI driver? Is it up to date and tested? Is there > >>> any > >>> > > code that uses it? I'd love to have a known good starting point. > >>> > > > >>> > > Cheers > >>> > > > >>> > > Rob > >>> > > > >>> > > >>> > >> >
[PATCH] doubt about fwrite
hi~
I connected the target board to terminal via "telnet" , in some cases
the terminal will be frozen. Here are detailed steps:
1. Enable "CONFIG_IOB_DEBUG"[necessary].
2. New two terminals and connect to target board via "telnet".
3. Input "dmesg" command,and the terminal will show information
*continuously*.[two terminals are same][necessary]
4. Close one of the terminals,and the other one will be frozen.but the
system is work on.
I debug the system and repaired the bug,the file named commit.txt is
detailed steps.
BR,
wei peng
diff --git a/nuttx/include/stdio.h b/nuttx/include/stdio.h
index 9a13052..033acbb 100755
--- a/nuttx/include/stdio.h
+++ b/nuttx/include/stdio.h
@@ -161,7 +161,7 @@ FAR FILE *freopen(FAR const char *path, FAR const char
*mode,
intfseek(FAR FILE *stream, long int offset, int whence);
intfsetpos(FAR FILE *stream, FAR fpos_t *pos);
long ftell(FAR FILE *stream);
-size_t fwrite(FAR const void *ptr, size_t size, size_t n_items,
+ssize_t fwrite(FAR const void *ptr, size_t size, size_t n_items,
FAR FILE *stream);
FAR char *gets(FAR char *s);
FAR char *gets_s(FAR char *s, rsize_t n);
diff --git a/nuttx/libs/libc/stdio/lib_fwrite.c
b/nuttx/libs/libc/stdio/lib_fwrite.c
index 6426b70..4713fa0 100755
--- a/nuttx/libs/libc/stdio/lib_fwrite.c
+++ b/nuttx/libs/libc/stdio/lib_fwrite.c
@@ -52,7 +52,7 @@
* Name: fwrite
/
-size_t fwrite(FAR const void *ptr, size_t size, size_t n_items,
+ssize_t fwrite(FAR const void *ptr, size_t size, size_t n_items,
FAR FILE *stream)
{
size_t full_size = n_items * (size_t)size;
@@ -67,6 +67,8 @@ size_t fwrite(FAR const void *ptr, size_t size, size_t
n_items,
/* Return the number of full items written */
items_written = bytes_written / size;
+}else{
+ items_written = bytes_written;
}
return items_written;
diff --git a/apps/nshlib/nsh_fsutils.c b/apps/nshlib/nsh_fsutils.c
index f6545d6..3eb2e7f 100755
--- a/apps/nshlib/nsh_fsutils.c
+++ b/apps/nshlib/nsh_fsutils.c
@@ -98,7 +98,7 @@ int nsh_catfile(FAR struct nsh_vtbl_s *vtbl, FAR const char
*cmd,
/* And just dump it byte for byte into stdout */
- for (;;)
+ while (ret >= 0)
{
int nbytesread = read(fd, buffer, IOBUFFERSIZE);
Re: [PATCH] doubt about fwrite
hi David, Thanks for your reply. Yes...i know the interface interface is standard,so what i had changed in codes just repaired the problem.perhaps i should describe the problem in detail. I entering "dmesg" on both terminals，because of the “CONFIG_IOB_DEBUG” is enable so both of terminals will show messages continuously. Then close one of them,and the other one will be frozen,after that i cannot connect the borad (via usart or telnet).but i am sure the systerm is work on. I found the "dmesg" command call a function named "int nsh_catfile()",and in this function,the logic is simple (read message from ramlog and write it to terminals). when write it to terminals ,it will call "size_t fwrite()"function, As you see the size_t is unsigned cannot be negative. that is the problem. i think if the terminal is close,the "size_t fwrite()"function should return a negative number,and the nsh_catfile should be broken. BR, wei peng David Sidrane 于2019年12月23日周一 下午5:36写道： > Hi wei peng > See below. > > On 2019/12/23 07:41:40, wei peng wrote: > > hi~ > > I connected the target board to terminal via "telnet" , in some cases > > the terminal will be frozen. Here are detailed steps: > > > >1. Enable "CONFIG_IOB_DEBUG"[necessary]. > >2. New two terminals and connect to target board via "telnet". > >3. Input "dmesg" command,and the terminal will show information > >*continuously*.[two terminals are same][necessary] > >4. Close one of the terminals,and the other one will be frozen.but > the > >system is work on. > > > > I debug the system and repaired the bug,the file named commit.txt is > > detailed steps. > > BR, > > > > wei peng > > The interface is dictated by the OpenGroup stands [1] > [1] https://pubs.opengroup.org/onlinepubs/009695399/functions/fwrite.html > > So that can not be changed. > > There must be a root cause related to what you are doing or a bug in the > system. Check the configuration (compare it to other telnet board configs). > > Are you Entering dmesg on both terminals or on one and it is showing up > the 2 terminals? > > David > >
Re: [PATCH] doubt about fwrite
Thanks for gregory and xiang. yes... the right way is modified the error handling code in nsh_catfile not fwrite. I will repaired it again. BR, wei peng Xiang Xiao 于2019年12月24日周二 上午9:58写道： > Hi Peng, > From http://www.cplusplus.com/reference/cstdio/fwrite/ > fwrite return zero to indicate the error, the detailed info could get > from errno. > So the right change is modified the error handling code in > nsh_catfile, not the return type of fwrite. > > Thanks > Xiang > > On Tue, Dec 24, 2019 at 9:48 AM wei peng wrote: > > > > hi David, > > > > Thanks for your reply. > > > > Yes...i know the interface interface is standard,so what i had changed in > > codes just repaired the problem.perhaps i should describe the problem in > > detail. > > > > > > I entering "dmesg" on both terminals，because of the “CONFIG_IOB_DEBUG” is > > enable so both of terminals will show messages continuously. > > Then close one of them,and the other one will be frozen,after that i > cannot > > connect the borad (via usart or telnet).but i am sure the systerm is work > > on. > > > > > > I found the "dmesg" command call a function named "int nsh_catfile()",and > > in this function,the logic is simple (read message from ramlog and write > it > > to terminals). > > when write it to terminals ,it will call "size_t fwrite()"function, As > you > > see the size_t is unsigned cannot be negative. that is the problem. > > i think if the terminal is close,the "size_t fwrite()"function should > > return a negative number,and the nsh_catfile should be broken. > > > > BR, > > > > wei peng > > > > David Sidrane 于2019年12月23日周一 下午5:36写道： > > > > > Hi wei peng > > > See below. > > > > > > On 2019/12/23 07:41:40, wei peng wrote: > > > > hi~ > > > > I connected the target board to terminal via "telnet" , in some > cases > > > > the terminal will be frozen. Here are detailed steps: > > > > > > > >1. Enable "CONFIG_IOB_DEBUG"[necessary]. > > > >2. New two terminals and connect to target board via "telnet". > > > >3. Input "dmesg" command,and the terminal will show information > > > >*continuously*.[two terminals are same][necessary] > > > >4. Close one of the terminals,and the other one will be > frozen.but > > > the > > > >system is work on. > > > > > > > > I debug the system and repaired the bug,the file named commit.txt is > > > > detailed steps. > > > > BR, > > > > > > > > wei peng > > > > > > The interface is dictated by the OpenGroup stands [1] > > > [1] > https://pubs.opengroup.org/onlinepubs/009695399/functions/fwrite.html > > > > > > So that can not be changed. > > > > > > There must be a root cause related to what you are doing or a bug in > the > > > system. Check the configuration (compare it to other telnet board > configs). > > > > > > Are you Entering dmesg on both terminals or on one and it is showing up > > > the 2 terminals? > > > > > > David > > > > > > >
