We have many units in customers’ hands using the uALFAT with SPI interface. Our data system generates and records binary files at the rate of about 20-25 MByte/hour, typically with 2 files open at any given time: one binary, the other ASCII as a much lower data rate (10x’s less). We have been experience increasing frequency of occurrence of the following event: after recording data for about 2 - 3 hours, the uALFAT will simply stop responding to commands. Since many clients have data logging sessions less than this, this problem hasn’t surfaced much over the past few years since we started using the uALFAT. However, this issue is cropping up more and more and we’re getting into trouble with clients losing data and demanding answers from us. The only thing we have managed as a fix so far is to have our firmware yank the reset line to the uALFAT once it stops seeing replies from the uALFAT, but this typically results in loss of data written up to that point. This has occurred across several different installations, using different make / mfg USB drives. The only thing common is period of time, i.e. the longer it runs, the higher the probability of what appears to be a uALFAT firmware crash event. Are you aware of ANYTHING that might cause the uALFAT firmware to crash and stop responding to commands? We are at a loss as we can’t trap events inside the uALFAT - it appears as a “black box” to our system. This coupled with the long + random period before the crash makes it exceptionally difficult to debug.
do you have power on VBAT pin? Did you check your crustal and it loading caps to be something within what is specified by NXP?
It appears that the chance of failure depends on the age of the thumb drive + amount of use. We can only assume that it is something about the USB drive that is giving the uALFAT problems leading to a fatal condition. We are moving on the of ALFAT board to see how it holds up.