- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hello,
I have almost the same problem as mentioned in the thread https://community.cypress.com/t5/Nor-Flash/SpansionFFS-with-SLLD-FTL-InitAll-fails/m-p/155153. However, the cause of the problem cannot be the same as in this thread as we are not using any level translator. We are using STM32G483VE MCU and S256FL256LAGMFI NOR flash. We can read id and status registers from the device, so the communication is working. However, when trying to use SpansionFFS, it always ends in the same condition as for JaAr_633041 - on line 274 at io_pim_spansion.c in function pim_ioctl_span_init(). Even though the formatting in FTL_Format() does not return any error, return code of the FTL_InitAll() function is 14 (FTL_ERR_NOT_FORMATTED) as if the formatting did not end correctly. The underlying problem is also the same, it is because FTL_FindSuperSysEB() on line 141 in the file ftl_init.c returns 28019. Then, formatCount is set 26 on line 188 and whole function fails as format is set to FTL_DONT_FORMAT.
In Format.h, we have changed the defines to have 4 KB sectors, 64 KB eblocks.
Preprocessor define __SLLD is defined in the IDE.
Write enable, write disable, sector erase, program, read and read status register commands are implemented in the slld layer.
Before calling any of the FFS APIs, slld_RDIDCmd() can be called and correctly returns 0x01 0x60 0x19 as specified in the datasheet.
We are stuck on this problem for days, do you have any idea what the problem can be?
Thanks in advance,
Karel
Solved! Go to Solution.
- Labels:
-
Memory Nor Flash
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi Takashiro,
you were correct from the beginning, it was issues with slld_hal.c layer. The problem was this: lines 196-208 and 304-316 in the slld hal I sent you is absolute nonsense. I should have written just
cmd.Address = sys_addr;
in both places and it would be enough. Sorry I did not notice it until now, such as stupid mistake. It came from when I was porting it from slld_hal_example.c. Another thing I was missing was setting number of dummy cycles in write, but I believe it should not be necessary.
The filesystem now sometimes fails in the mounting stage, but I think it is because I formatted the flash so many times, that some sectors are too worn. On our other board with the same hardware it works correctly now.
I would like to thank you for excellent support which lead me in the right direction, especially your idea to put debug printfs to the low-level functions lead me right to the root of my issues.
Last thing I want to mention is that NUMBER_OF_BYTES_PER_SECTOR must not be larger than PIM_ALLOW_MAX_SECT_SIZE in ion_pim.h as this define then allocates buffer of this size and if it is smaller, it overflows and (at least my) program goes to hard fault handler. I think it should maybe be mentioned in documentation as I did not find it anywhere. But it is a small issue that can be found quickly.
Thank you for your help,
Karel
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hello,
Thank you for contacting Cypress Technical Support, an Infineon Technologies Company. Is it possible for you to share your project/code/screenshot with us?
Regards,
Bushra
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hello Bushra,
Thank you for your reply.
This is where pim_ioctl_span_init() fails beacuse FTL_InitAll() returns FTL_ERR_NOT_FORMATTED :
This is the reason, formatCount is 26, NUM_SYSTEM_EBLOCKS is also 26 and initStructPtr->format is INIT_DONT_FORMAT :
There are our settings in Format.h:
NUMBER_OF_ERASE_BLOCKS is 512. We also tried setting NUMBER_OF_SECTORS_PER_PAGE to (1) but with no luck.
In the attachment I send you our slld_hal.c layer. Do you want to send some more code from me?
Regards,
Karel
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi Karel,
Please review your "SLLD/src/slld_targetspecific.h" and make sure that:
- USE_4B_ADDR_CMDS is defined
- USE_4B_ADDR_BAR is NOT defined
The FL256L has 32MB density and requires 4B addressing. The FL-F family does not support Bank Address Register (BAR).
Thanks,
Takahiro
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hello Takahiro,
you were correct, we had those defines wrong - USE_4B_ADDR_CMDS was not defined. However, now it is defined correctly but the problem is still the same.
Thanks,
Karel
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi Karel,
This failure is typically caused by read/write protocol mismatch between host SPI controller/driver and device configuration, including addressing mode.
Is it possible to instrument printf() or something into your slld_hal.c to trace command and address bytes transmitted?
And could you share the Configuration Register 1-3 values in your FL256L, if you changed from default settings?
Thanks,
Takahiro
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi Takahiro,
I have a suspicion that the FTL_Format() function does not work correctly due to some issues with the erasing of the blocks. For simplification, in next examples I am using only 32 blocks instead of all 512. The problem with formatting can be seen from the following output (I now use printf()).
First a little clarification, I enabled all the debug prints in the SpansionFFS. Then, I implemented printing in the slld_hal.c layer in the read and write functions. Format is following: first is the function called (Read or Write), next is number of the command, next is the address (all in hex). After the address there are the bytes sent / received (if any). Furthemore, commands with ID 0x5 and 0x7 are not shown - there is too much of them and I know I am reading the busy bit in the status register correctly.
So this is the output when calling FTL_Format() only:
FTL_EraseOp: Erase Logical EBlock 0x0, physical EBlock 0x0
Write: 6, ffffffff
Write: 21, 0
Write: 4, ffffffff
FTL_EraseOp: Erase Logical EBlock 0x1, physical EBlock 0x1
Write: 6, ffffffff
Write: 21, 10000
Write: 4, ffffffff
FTL_EraseOp: Erase Logical EBlock 0x2, physical EBlock 0x2
Write: 6, ffffffff
Write: 21, 20000
Write: 4, ffffffff
FTL_EraseOp: Erase Logical EBlock 0x3, physical EBlock 0x3
Write: 6, ffffffff
Write: 21, 30000
Write: 4, ffffffff
FTL_EraseOp: Erase Logical EBlock 0x4, physical EBlock 0x4
Write: 6, ffffffff
Write: 21, 40000
Write: 4, ffffffff
FTL_EraseOp: Erase Logical EBlock 0x5, physical EBlock 0x5
Write: 6, ffffffff
Write: 21, 50000
Write: 4, ffffffff
FTL_EraseOp: Erase Logical EBlock 0x6, physical EBlock 0x6
Write: 6, ffffffff
Write: 21, 60000
Write: 4, ffffffff
FTL_EraseOp: Erase Logical EBlock 0x7, physical EBlock 0x7
Write: 6, ffffffff
Write: 21, 70000
Write: 4, ffffffff
FTL_EraseOp: Erase Logical EBlock 0x8, physical EBlock 0x8
Write: 6, ffffffff
Write: 21, 80000
Write: 4, ffffffff
FTL_EraseOp: Erase Logical EBlock 0x9, physical EBlock 0x9
Write: 6, ffffffff
Write: 21, 90000
Write: 4, ffffffff
FTL_EraseOp: Erase Logical EBlock 0xA, physical EBlock 0xA
Write: 6, ffffffff
Write: 21, a0000
Write: 4, ffffffff
FTL_EraseOp: Erase Logical EBlock 0xB, physical EBlock 0xB
Write: 6, ffffffff
Write: 21, b0000
Write: 4, ffffffff
FTL_EraseOp: Erase Logical EBlock 0xC, physical EBlock 0xC
Write: 6, ffffffff
Write: 21, c0000
Write: 4, ffffffff
FTL_EraseOp: Erase Logical EBlock 0xD, physical EBlock 0xD
Write: 6, ffffffff
Write: 21, d0000
Write: 4, ffffffff
FTL_EraseOp: Erase Logical EBlock 0xE, physicalWrite: 4, ffffffff
FTL_EraseOp: Erase Logical EBlock 0x10, physical EBlock 0x10
Write: 6, ffffffff
Write: 21, 100000
Write: 4, ffffffff
FTL_EraseOp: Erase Logical EBlock 0x11, physical EBlock 0x11
Write: 6, ffffffff
Write: 21, 110000
Write: 4, ffffffff
FTL_EraseOp: Erase Logical EBlock 0x12, physical EBlock 0x12
Write: 6, ffffffff
Write: 21, 120000
Write: 4, ffffffff
FTL_EraseOp: Erase Logical EBlock 0x13, physical EBlock 0x13
Write: 6, ffffffff
Write: 21, 130000
Write: 4, ffffffff
FTL_EraseOp: Erase Logical EBlock 0x14, physical EBlock 0x14
Write: 6, ffffffff
Write: 21, 140000
Write: 4, ffffffff
FTL_EraseOp: Erase Logical EBlock 0x15, physical EBlock 0x15
Write: 6, ffffffff
Write: 21, 150000
Write: 4, ffffffff
FTL_EraseOp: Erase Logical EBlock 0x16, physical EBlock 0x16
Write: 6, ffffffff
Write: 21, 160000
Write: 4, ffffffff
FTL_EraseOp: Erase Logical EBlock 0x17, physical EBlock 0x17
Write: 6, ffffffff
Write: 21, 170000
Write: 4, ffffffff
FTL_EraseOp: Erase Logical EBlock 0x18, physical EBlock 0x18
Write: 6, ffffffff
Write: 21, 180000
Write: 4, ffffffff
FTL_EraseOp: Erase Logical EBlock 0x19, physical EBlock 0x19
Write: 6, ffffffff
Write: 21, 190000
Write: 4, ffffffff
FTL_EraseOp: Erase Logical EBlock 0x1A, physical EBlock 0x1A
Write: 6, ffffffff
Write: 21, 1a0000
Write: 4, ffffffff
FTL_EraseOp: Erase Logical EBlock 0x1B, physical EBlock 0x1B
Write: 6, ffffffff
Write: 21, 1b0000
Write: 4, ffffffff
FTL_EraseOp: Erase Logical EBlock 0x1C, physical EBlock 0x1C
Write: 4, ffffffff
FTL_EraseOp: Erase Logical EBlock 0x1D, physical EBlock 0x1D
Write: 6, ffffffff
Write: 21, 1d0000
Write: 4, ffffffff
FTL_EraseOp: Erase Logical EBlock 0x1E, physical EBlock 0x1E
Write: 6, ffffffff
Write: 21, 1e0000
Write: 4, ffffffff
FTL_EraseOp: Erase Logical EBlock 0x1F, physical EBlock 0x1F
Write: 6, ffffffff
Write: 21, 1f0000
Write: 4, ffffffff
Write: 6, ffffffff
Write: 12, 150000 ed 0 1 ff 15 0 ff ff ff ff ff ff 0 0 0 0 ed 0 1 ff 15 0 ff ff ff ff ff ff 0 0 0 0
Write: 4, ffffffff
Write: 6, ffffffff
Write: 12, 1a0000 a7 c1 2 ff 1a 0 3f 3f ff ff ff ff 0 0 0 0 a7 c1 2 ff 1a 0 3f 3f ff ff ff ff 0 0 0 0
Write: 4, ffffffff
Read: 13, 150000, ed 0 1 ff 15 0 c1 2 ff 1a 0 3f 0 0 0 0 ed 0 0 0 0 0 c1 2 ff 1a 0 3f 0 0 0 0
My impression is that the sector beginning on address 0x150000 is not erased correctly and some bits are left at zero. It would correspond with the incorrect read on the last line, where only first six bits are correct. I think this is underlying problem of all my issues, because this function fails every time, but I am not sure what is the cause of it.
Another thing is that when I put breakpoint right after the erasing of the sectors (line 900 in FTL_InternalFormat() in ftl_init.c):
and then I end the program and in a new run try to read the 32 bytes at 0x150000, they are all correctly reset to 0xFF. So it would seem that all this is some timing issues.
Next, the status/config registers as you requested:
I did not change them and therefore I would suppose they are correct. The QSPI mode is disabled as I am for now using the SPI commands as you could see.
Also, I attach whole run of the sample program sample_spn_fs(). The output is not complete and some data are missing, but I cannot make the debugger cooperate with longer ouptuts, sorry for that. But there is apparent some weird shifting in the consecutive reads, which would maybe suggest that my hypothesis with timing issues is correct but I am really none the wiser from it. Hope this helps you...
Thanks and regards,
Karel
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi Takashiro,
you were correct from the beginning, it was issues with slld_hal.c layer. The problem was this: lines 196-208 and 304-316 in the slld hal I sent you is absolute nonsense. I should have written just
cmd.Address = sys_addr;
in both places and it would be enough. Sorry I did not notice it until now, such as stupid mistake. It came from when I was porting it from slld_hal_example.c. Another thing I was missing was setting number of dummy cycles in write, but I believe it should not be necessary.
The filesystem now sometimes fails in the mounting stage, but I think it is because I formatted the flash so many times, that some sectors are too worn. On our other board with the same hardware it works correctly now.
I would like to thank you for excellent support which lead me in the right direction, especially your idea to put debug printfs to the low-level functions lead me right to the root of my issues.
Last thing I want to mention is that NUMBER_OF_BYTES_PER_SECTOR must not be larger than PIM_ALLOW_MAX_SECT_SIZE in ion_pim.h as this define then allocates buffer of this size and if it is smaller, it overflows and (at least my) program goes to hard fault handler. I think it should maybe be mentioned in documentation as I did not find it anywhere. But it is a small issue that can be found quickly.
Thank you for your help,
Karel