Programming spare area of Samsung K9F1G08U0B 128Meg NAND

[Guest]

Hi,

We are trying to program up a Samsung K9F1G08U0B 128 Meg NAND device, which our device splits into several 'partitions'. Each partition uses a different layout for the spare area, as such we need to provide the spare area data when programming the chip.

We have created a file for each 'partition', that contains 2k of data followed by the 64 bytes of 'spare' data, followed by the next 2k of data and 64 bytes of 'spare' data, and so on. We have loaded each of these files into the buffer at the appropriate offset.

However when the device was programmed, a block that should have been in page 64 appears to have actually been written to page 66. This offset co-incidentally coincides with 64 pages worth of spare area, so we think that the spare data in our files has actually been taken as 'normal' data. Additionally, the ECC fails on this block, further indicating that the spare area hasn't been written correctly.

Can you please tell me (or point me to some appropriate documentation) how we can provide files to the programming software such that the appropriate data and spare data is written in the correct locations?

Thanks

Andy Hawkins
Software Engineer

[Guest]

An additional question, regarding bad blocks.

If a bad block is skipped in the first 'partition', then we need the second partition to still start at the correct offset into the flash, not be offset by 1 due to the skipping of the bad block in the first partition.

Can you tell me what settings to apply to achieve this?

Thanks

Andy

[Dataman (Neil Parker)]

Hello Andy,

If you have not already, please download our "NAND Flash Memories and Programming of NAND Flash Memories Using Dataman Device Programmers" manual which can be found here.

If you find that it does not answer you specific questions then please let me know and I will do my best to help.

Best regards,

Neil Parker
Dataman Programmers

[Guest]

Thanks, I'll take a look at that.

I've had some further information from the people that actually did the programming, and it seems they changed the device type slightly, which will have reset a lot of the parameters without them realising.

We're trying it again to see if it works any better given the correct parameters.

Thanks

Andy

[Guest]

Ok, we've done some further testing and it appears to be writing the flash correctly now.

However, I think that if we get a bad block early on in the flash, subsequent 'partitions' are being shifted by the bad block.

For example, if we have a flash containing 20 blocks, Split into two partitions, the first blocks 0-9, and the second blocks 10-19.

We want to write the flash like this:

0 - partition 1 data 1
1 - partition 1 data 2
2 - partition 1 data 3
3 - partition 1 data 4
4 - partition 1 data 5
5 - partition 1 data 6
6 - partition 1 data 7
7 - blank
8 - blank
9 - blank
10 - partition 2 data 1
11 - partition 2 data 2
12 - partition 2 data 3
13 - partition 2 data 4
14 - partition 2 data 5
15 - blank
16 - blank
17 - blank
18 - blank
19 - blank

If we have a bad block at block 3, we would expect to see

0 - partition 1 data 1
1 - partition 1 data 2
2 - partition 1 data 3
3 - bad block skipped
4 - partition 1 data 4
5 - partition 1 data 5
6 - partition 1 data 6
7 - partition 1 data 7
8 - blank
9 - blank
10 - partition 2 data 1
11 - partition 2 data 2
12 - partition 2 data 3
13 - partition 2 data 4
14 - partition 2 data 5
15 - blank
16 - blank
17 - blank
18 - blank
19 - blank

However, what we appear to be seeing is:

0 - partition 1 data 1
1 - partition 1 data 2
2 - partition 1 data 3
3 - bad block skipped
4 - partition 1 data 4
5 - partition 1 data 5
6 - partition 1 data 6
7 - partition 1 data 7
8 - blank
9 - blank
10 - blank
11 - partition 2 data 1
12 - partition 2 data 2
13 - partition 2 data 3
14 - partition 2 data 4
15 - partition 2 data 5
16 - blank
17 - blank
18 - blank
19 - blank

As you can see, partion 2's start data is now at block 11, not at block 10 where the application (in this case, the linux kernel looking for a filesystem) is looking for it. This causes the filesystem mount to fail, as instead of the filesystem signature, the kernel sees an 'empty' block.

One way around this would be to have multiple 'projects', where each project just programs up the individual partitions at the correct locations (by specifying the correct address for the start of the user area). However, unless this could be automated it would be incredibly difficult in a production setting.

Is there an option in the software to do what we want (i.e. skip bad blocks, but force the start of each 'partition' to be fixed)?

Thanks

Andy

[Dataman (Neil Parker)]

Hello adhawkins,

> Is there an option in the software to do what we want (i.e. skip bad
> blocks, but force the start of each 'partition' to be fixed)?

We will check this situation with our engineers. Can you provide us with your project file so that we can start from the same point? You can email it to me at support@dataman.com

> One way around this would be to have multiple 'projects', where each
> project just programs up the individual partitions at the correct
> locations (by specifying the correct address for the start of the user
> area). However, unless this could be automated it would be incredibly
> difficult in a production setting.

This process can be automated, please see this application note on the subject.

Best regards,

Neil Parker
Dataman Programmers

[Guest]

We will check this situation with our engineers. Can you provide us with your project file so that we can start from the same point? You can email it to me at support@dataman.com

That won't be easy, as it's a 20 meg file. Can I put a copy on our web site and email you the link?

This process can be automated, please see this application note on the subject.

That looks good. I've had a quick look at the document and it appears to be aimed at doing different devices in each sub-project. Presumably it'll work if all of the devices in the projects are the same type?

Thanks

Andy