SpansionFFS with SLLD: FTL_InitAll() fail

Tip / Sign in to post questions, reply, level up, and achieve exciting badges. Know more

cross mob
kachna5247
Level 2
Level 2
5 replies posted 5 sign-ins First solution authored

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

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

0 Likes
1 Solution
kachna5247
Level 2
Level 2
5 replies posted 5 sign-ins First solution authored

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

View solution in original post

0 Likes
7 Replies
BushraH_91
Moderator
Moderator
Moderator
750 replies posted 50 likes received 250 solutions authored

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

 

0 Likes
lock attach
Attachments are accessible only for community members.
kachna5247
Level 2
Level 2
5 replies posted 5 sign-ins First solution authored

Hello Bushra,

Thank you for your reply.

This is where pim_ioctl_span_init() fails beacuse FTL_InitAll() returns FTL_ERR_NOT_FORMATTED :

span_init.png

This is the reason, formatCount is 26, NUM_SYSTEM_EBLOCKS is also 26 and initStructPtr->format is INIT_DONT_FORMAT :

initall.png

There are our settings in Format.h:

format.png

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

0 Likes

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

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

0 Likes

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

lock attach
Attachments are accessible only for community members.

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):

flash_erase_done.png

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:

regs.png

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

0 Likes
kachna5247
Level 2
Level 2
5 replies posted 5 sign-ins First solution authored

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

0 Likes