File writing tasks silently failing on K60 and K64F

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

File writing tasks silently failing on K60 and K64F

Jump to solution
3,893 Views
ironsean
Contributor V

Hello, I've experienced an issue using MFS and a file writing task on

both a K60 custom board, and a K64F FRDM board: When the fopen() or

write() function is called the function will never return and the task will

cease operating. There are no errors thrown and I don't know where to

look to figure out why the function ceased. If I step through line by line

in the debugger eventually the debugger will just stop responding as

well.

It happened first with a custom K60 based board, using MFS on the

Internal Flash (to facilitate developing the file logic until a new board with

better storage was developed). When a specialized test task wrote to

Flash it worked, and when ONLY the file writing task (not the webserver,

telnet server, sensor reading, or data uploading tasks) it also worked.

But when all the tasks were running the file writing would silently stop

the task. By lowering the priority of the file writing task to the lowest

priority it began to function properly.

Now, on the K64F FRDM board we are attempting to refactor that task

to use the SD card. The internal flash writing still works. We have also

used the SD card example application to verify the SD card writing

works. I moved the SD card initialization into our full project and it

installs and uninstalls the SD card appropriately, but whenever we try to

write to it the task silently fails again.

Any idea where or how I could try and Troubleshoot this, or what might

be happening? Because of the task priority and the way it just ceases, I

wondered if there's some sort of deadlock that occurs with the file

writing task and one of the others. Priority doesn't seem to be helping

the SD card case though.

We're using CodeWarrior Version: 10.5

     Build Id:130916

Labels (1)
0 Kudos
1 Solution
2,130 Views
ironsean
Contributor V

I have confirmed that stack overflows were the course of my issues. I discovered it when another task was crashing on printf calls, and realized the printf was buffering the output and overflowing the stack. After realizing I went back and that was exactly what was happening with the SD card writing task. I used the Codewarrior task summary and stack usage tools to monitor this.

Since this is not the case with you I'm less sure. Could you possibly be running out of memory elsewhere?

View solution in original post

0 Kudos
28 Replies
308 Views
RadekS
NXP Employee
NXP Employee

Could you please specify which priorities you used for your tasks?

General recommendation is do not use priority levels below 8 for tasks, because they could block some internal interrupts typically used for io operations.

Could you please specify your parameters for fopen()?

Unfortunately MQX up to 4.1.1 contains bug in append mode. Unfortunately, append mode is implemented wrongly.

As workaround, please use r+/w/w+ modes instead of append mode and seeks manually according your needs.

Next MQX release will contain complete redesigned MFS subsystem which will solve this issue.

There is also one additional bug in MFS specific only for MQX for FRDMK64F/TWRK64F120M and MQX 4.1.1:

https://community.freescale.com/message/441581


Have a great day,
RadekS

-----------------------------------------------------------------------------------------------------------------------
Note: If this post answers your question, please click the Correct Answer button. Thank you!
-----------------------------------------------------------------------------------------------------------------------

308 Views
ironsean
Contributor V

No priorities below 8, and in fact the file writing only worked on the K60 with the lowest priority of the tasks.

{ MAIN_TASK,main_task,1200,9,"Main",MQX_AUTO_START_TASK,0,0},
{ HTTP_TASK,http_task,1200,16,"http",0,0,0},
{ SONAR_TASK,sonar_task,1200,11,"sonar",MQX_FLOATING_POINT_TASK,0,0},
{ TEST_TASK,test_task,1000,13,"test",0,0,0},
{ TELNET_TASK,telnet_task,1000,14,"telnet",0,0,0},
{ SENDER_TASK,sender_task,1000,12,"sender",0,0,0},
{ READ_TASK,read_task,1000,12,"read",0,0,0},
{ LOG_TASK,log_task,1000,18,"log",0,0,0},

I am in fact using the append modes, with this call:

logfile = fopen("MFS:level_log.dat", "a+");

Weirdly, the append mode seems to work fine on the internal flash, and on the previous chip, just not with the SD card. Also, the task doesn't stop on the fopen() call but on the write() call. Do you have any more information about this append bug so I can find out what's going on and what to expect, and if this may be the cause of my issue? Also, any ETA on the next MQX release? With that K64 specific bug in fseek, and append mode not working properly I might need to just wait.

0 Kudos
308 Views
RadekS
NXP Employee
NXP Employee

Thank you for additional information.

MQX 4.0.2 has problem in flashX (I am not sure if you use it) with data in cache. Write followed by read caused that you read wrong data. MQX4.1 contains fix with invalidate this cache.

Problem with append mode appears when file size is multiply of cluster size. See also:

https://community.freescale.com/message/441854

So, it typically works for few hundreds writes and after that it stops.

308 Views
ironsean
Contributor V

RadelS,

Is there any time frame for the next version of MQX to be released? Between the append mode bug locking the file at the cluster size and the IO_SEEK_END bug where MQX doesn't properly update the filesize trying to write to files is a heachache right now. I can think of some ways around it but it's going to be a big pain to implement.

0 Kudos
308 Views
RadekS
NXP Employee
NXP Employee

Current plan for MQX 4.2 is Q2 2015.

In fact, new MFS was already released in package MQX 4.1.2 (for Vybrid) and also in Kinetis SDK 1.1.0.

If you need it, you can cut out it from these packages.

From MQX 4.1.2 Release notes:

MFS library was updated with this functionality:

• Support for multiple concurrent readers/writers of the same file

• Support of mutex in addition of lwsem - solution to priority inversion

• Locking mechanism reviewed

• Read only checks - improved efficiency

• Better abstraction of FAT chain handling – better performance of random seek

• Scalable sector cache layer – dedicated directory and FAT sector buffers were removed

• True file append mode – seek to end of file atomically prior each write operation

• Legacy open mode "x" for creating temporary files was removed – the caller shall generate a unique file name

according to the use case

• Speed and CodeSize optimizations

I hope it helps you.

0 Kudos
308 Views
ironsean
Contributor V

Thank you. Assuming MQX 4.1.2 is not releasing for Kinetis on Codewarrior anytime soon, I'll see about taking the MFS implementation from there.

Sean

0 Kudos
308 Views
RadekS
NXP Employee
NXP Employee

Yes, 4.1.2 is standalone package just for Vybrid products.

There will not be any 4.1.2 package for Kinetis MCUs. Next release will be 4.2.

0 Kudos
308 Views
ironsean
Contributor V

Thank you for more information. I can confirm that my issues are not related to the append functionality (writing either works, or fails completely if I'm using the SD card), and I haven't written far enough to find the cluster size append error. I have even changed to "w" mode to overwrite new files and the issue is still the same.

The caches are all set to write-through for my application, as it's more resilient to power loss or SD card removal. But the functionality fails before writing anyway.

I am testing again now, and once the fopen() executes on the MFS:, which is installed without error on the sdcard:, the LED beside the card on the K64 turns red and blue, and the task ceases.

0 Kudos