This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

Some question about psp_nand of DSP/BIOS5

I try to use the wear-leveling feature of nand flash driver in a C6747 device without operating system. So I try to migrate the nand module of PSP (Platform Support Package) for DSP/BIOS 5.x to my code (That is to say, remove the code using BIOS APIs). I have tested my program by writing some data to flash then read them and compared, the test is passed.

But there are 2 questions about the psp nand driver:

1. Why printf() will crash after calling "Int32 PSP_nandWrite(Ptr          handle, Uint32       logSector,   Uint32       numSectors,   Uint8        *data)" I have set the stack size to 0x30000 in a 16MB SDRAM? Calling "Int32 PSP_nandRead(Ptr          handle,  Uint32       logSector,  Uint32       numSectors,   Uint8        *data)" won't make printf() crash.

2. According to the function signature of PSP_nandWrite() and PSP_nandRead(), and I have read through the source code of psp nand,  as if the functions suggest the data buffer should be the integer multiple of Nand flash page size. If I just want to write or read 2 bytes data, then the data buffer will be overflow unless my data buffer is as large as a page.

I want to encapsulate a function API like "MyPSP_nandWrite(Ptr handle, Uint32 logSector, Uint8* data, Uint32 size)" based on the psp nand driver. Each parameters are described below:
               - handle : The handle of nand (The same as the corresponding param of function PSP_nandWrite)
               - logSector : The start logical sector to write (The same as the corresponding param of function PSP_nandWrite)
               - data : The pointer to the data buffer in memory need to be written (The same as the corresponding param of function PSP_nandWrite)
               - size : The size of the data buffer
Exactly, the param (numSectors) can be calculated according to the size of data buffer and the page size of nand flash. If the size of data buffer is less than one page size, the written operation can be treat as write the data in the buffer to the page, then write some invalid data to fill the whole page. I think this kind of API won't cause the buffer overflow if I have parameter check.

I hope the experts and friends in this community will help me to answer the 2 questions above. Thanks a lot.

(P.S. I'm a Chinese, I don't know whether my expressions of English is clear enough, I hope it won't make you confused. If you have some problems to understand it, I will try to make it much more clear. Thank you all in advance)

  • Hi Shan Wang,

    I guess, you are referring to BIOS PSP 1.30.01. Am i right?

    Shan Wang said:

    1. Why printf() will crash after calling "Int32 PSP_nandWrite(Ptr          handle, Uint32       logSector,   Uint32       numSectors,   Uint8        *data)" I have set the stack size to 0x30000 in a 16MB SDRAM? Calling "Int32 PSP_nandRead(Ptr          handle,  Uint32       logSector,  Uint32       numSectors,   Uint8        *data)" won't make printf() crash.

    Since you have written your own NAND driver and not using the BIOS PSP driver or the APIs, it is difficult to analyze the crash. Can you please elaborate the crash scenario, so that we can see is it because of the NAND read/write calls or any other means.

    Shan Wang said:

    2. According to the function signature of PSP_nandWrite() and PSP_nandRead(), and I have read through the source code of psp nand,  as if the functions suggest the data buffer should be the integer multiple of Nand flash page size. If I just want to write or read 2 bytes data, then the data buffer will be overflow unless my data buffer is as large as a page.

    I want to encapsulate a function API like "MyPSP_nandWrite(Ptr handle, Uint32 logSector, Uint8* data, Uint32 size)" based on the psp nand driver. Each parameters are described below:
                   - handle : The handle of nand (The same as the corresponding param of function PSP_nandWrite)
                   - logSector : The start logical sector to write (The same as the corresponding param of function PSP_nandWrite)
                   - data : The pointer to the data buffer in memory need to be written (The same as the corresponding param of function PSP_nandWrite)
                   - size : The size of the data buffer
    Exactly, the param (numSectors) can be calculated according to the size of data buffer and the page size of nand flash. If the size of data buffer is less than one page size, the written operation can be treat as write the data in the buffer to the page, then write some invalid data to fill the whole page. I think this kind of API won't cause the buffer overflow if I have parameter check.

    Yes, as you have mentioned, you can have a seperate layer which can,

    1. Check for data alignment, if it is not, then throw an error OR temporarily copy the data to an aligned buffer (which can be provided to EDMA) [Refer blockmedia module in the BIOS PSP] 

    2. Convert the data size into the actual number of sectors and if the remaining data is less than page size then append buffer with some data, then write to the NAND (As you have mentioned above) 

    Regards,

    Sandeep K

  • Thank you very much Sandeep.

    I have solved the first problem. Because I mounted a 4KB Page size NAND Flash on the C6747. But the driver only supports 2KB Page size in maximum. I have modified some macros to support my flash device, but not all. So the array for calculate the ecc data has been overflow, which causes the printf() doesn't work.

    The second question I have solved it by encapsulate the API according to your suggestion. You mean Blockmedia module will check the data alignment. I'm just curious about that why TI didn't check it on the lower layer, like LLC, just for guaranteeing the efficiency of driver? Perhaps your answer will teach me how to design a driver properly. Thank you in advance.

    Regards

    Shan Wang