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

[sara]

can u please tell which tasks are they where I am accessing flash in the wrong way?

[Susheel Nuguru]

I do not know as i do not know the specs of this chip and this chip is external to Nordic so I do not have knowledge on it.

You said that it works with one task right? I would recommend you to add only one more task for testing to see how it goes and if the flash access does not work as intended then you can debug the code in the other task you accessed. This way you can exclude tasks which are functioning ok.

I also think debugging this without any logic analyzer or oscilloscope to proble I/O pins will be difficult.

[sara]

ok thanku Susheel , and yes i have checked with gsr n spo2 tasks working together and I used to get only 1-2% of error rate but when i introduce MIC task the issue arises. Meanwhile I will see if am able to manage logic analyzer or not as its a bit difficult for me to get it ryt now

[sara]

Hello Susheel, after trying to debug the issue I can confirm that when all 3 tasks working together when the data has been collected the value reads zero sometimes for this I found out that even if the value is written properly it reads wrong but when it is written n read immediately after that then it reads correct value but when later all the tasks have completed recording then when I read it gives wrong data sometimes so for this what can be the issue n how can I correct it?? Secondly I have a doubt can semaphore working be a problem ? I mean when it is released then there can be delay in taking it or vice-versa? I mean is there a way how can achieve tasks synchronous in such scenario?

[Susheel Nuguru]

Sara,

If the tasks are holding the semaphore for the whole transaction for that sensor (read/write/read_write) then you should not see any issues here. I think, the issue here is that the semaphore is being released too early and the other task is starting a read/write/read_write operation when the sensor has not still not finished completely from the previous operation. I would focus a bit more on the logic you have around releasing/locking this semaphore. Probably the sensor takes few us/ms more than what you think a read/write transaction needs from your driver? Try adding some timer delay (NOT busy loop) before and after every transaction (read/write/read_write) to fake extra time given for the transaction to complete and see if that helps. If it  does then you need to reconsider your semaphore release/locking logic

[sara]

Hello Susheel,

for delay u meant to use nrf_delay_ms(). ??

[Susheel Nuguru]

yes, busy delay would be easiest here just to give the external sensor time to complete the previous transaction. In any case comparing the timings of a transaction on the logic analyzer would have made your job easier to see why introduction of  MIC task  changes the states/timing of the data exchanged.