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.
Hi team,
My customer found that in Fls_Brd_Nor_Qspi.c, both functions Fls_norBlankCheck()/Fls_norCompare() will run away. Cause there is a null pointer written in the function, which causes the program to run away after the flash is erased. As shown below, the value of readData_buf is always NULL.
Hi Bruce,
Can I know what do you mean by "run away?" Is customer facing any issues while running the application or during the integration? If yes, please let us know the error or output.
, which causes the program to run away after the flash is erased.
I don't think this is gonna happen because we also pass the length of block to be comapred or erased or written etc., So, I didn't get the problem the customer is facing. Please ask the customer to elaborate the query.
Thanks,
G Kowshik
Hi Kowshik,
Hi Bruce,
Your understanding on the initializing the readBuf pointer to NULL is slightly wrong. With the statment *readData_buf = NULL we are assigning the value of the 1st element to 0, but not the address of the readData_buf to NULL. Hence the program will work correctly. The buffer is going to be allocated in the program stack memory not in the 0x00 location as you mentioned. You can compile the program and look at the map file which gives you the location of this buffer.
Thanks
Hi Kowshik,
I updated the reproducible project that you can try in your side, and you will see the same result shown in below!
Hi Bruce,
I confirmed that this is a bug in MCAL and filed it as high priority in our JIRA, here's the ticket for tracking [MCAL-10748] Fls driver over writing Vector table thereby causing Undefined aborts - Texas Instruments JIRA