using external flash MX25R1635FZUIL0 with nrf52 - having issues of writting and reading when multiple tasks are using the flash

[sara]

Hello, I am using MX25R1635FZUIL0 with nrf52  and my device is working with freertos.  I have three different tasks using/accessing  the flash functions but when i read back the data for all the 3 tasks i read some values as 0 and some as 0xFF and some correct values. But I need 100% correct data.my task 1 n 2 are sampling data at a speed of 256 Hz and then calling flash write function so when these two works together my error rate reduces but when i start the 3rd task which samples data at 16kHz i get only 1-2 % correct data for task 1 n 2 and almost all 0xFF for task 3. Can anyone please help me what should i do to get all the data correctly from flash 

[Susheel Nuguru]

I have never used this IC so i do not know the timing requirement it has with read sampling.  You should connect the IO pins to a logic analyzer to see if the third task is interfering with read transactions and changing the timings somehow. 

[sara]

thanks for ur reply Susheel, but if i run the task 3 alone having sampling rate of 16kHz it works properly but only when all 3 working issue arises. so will it interfere with read instructions? and apart from logic analyzer is there any other way i can find the issue?

[Susheel Nuguru]

I think we need to understand the IO lines when only task3 is running vs all task running. Maybe you can show code snippets of each task showing how they access the flash. Also how does the tasks yield and resume? what kind of scheduling are you using?

[sara]

as m working from home i do not have logic analyzer. And yes can share the code snippets. will make dummy tasks for u to understand as it's a big code 

[sara]

m sending u the zip file where gsr_task is task1 spo2_task is 2 and mic_task is 3

[Susheel Nuguru]

I can see that in all the tasks you are handling the flash events using the Queue with ext_flash_queue_handle. So they should not be conflicting with each other as the processing is only done in ext_flash.c. 

I think there is one flash access in two of your other tasks that probably access flash in the wrong way and hence making the MX25R chip go into some unstable state after that?