Robin Hourahane

Important changes to forums and questions

All forums and questions are now archived. To start a new conversation or read the latest updates go to forums.mbed.com.

8 years, 11 months ago.

Failure when using large frames on FRDM-K64F

Hi,

If I enable large frames on my FRDM-K64F the test program fails with "failed to create file". The program works with small frames. I believe that the hardware supports 16bit frames as I've used them before to drive an LCD screen.

Any ideas what could be going wrong?

Thanks

Robin

Question relating to:

Last updated: 29 Aug 2016
A re-written SDFileSystem library with improved compatibility, CRC support, and card removal/replacement support. fatfilesystem, MMC, SD, SD Card, SDHC, SDXC

I responded on my answer, just making sure you get a mail

posted by Erik - 10 May 2015

Hey Robin, if you still hang out on ARM mbed, did you do anything special to use SDFileSystem on the FRDM K64F? I am having a lot of trouble doing so. (See https://developer.mbed.org/questions/62085/No-response-from-SD-card-on-FRDM-K64F)

posted by Aaron Campbell 16 Jan 2016

I haven't done much with this for quite a while so I'm using an old version 16:c2c1f0b16380 which works for me. I suppose there could be a change in one of the newer versions that breaks it on the K64F.

posted by Robin Hourahane 16 Jan 2016

Turns out the problem was that my offline compiler made chars signed, where as this library assumes chars are unsigned.

posted by Aaron Campbell 05 Feb 2016

3 Answers

Just Gary
8 years, 11 months ago.

A few months ago, I was playing with a string of individually addressable RGB LEDs. I noticed that switching to 16 bit transmissions caused the LEDs to display the wrong color after the first few. I eventually traced it to the fact that the K64F drops the fourth pair (as I recall) of the transmission. After placing a dummy 16-bit word in the correct place (so the K64F could drop that instead of my data), the LEDs all displayed properly. This behavior was identical whether I did it in a loop or via DMA.

The problem did not occur when I wrote to only half the string. I didn't take the time to investigate further, but the non-working transmission was 160*3/2 = 240 transmissions (16 bits each), and the working one was 120. I also tried 60 transmissions, and that worked fine as well.

So, I suspect that the SPI core in the K64F may have some kind of bug with long transmissions.

By the way, I found the problem by writing sequential bytes out, then verifying on my oscilloscope that it indeed failed to write two bytes.

Hmm that i did not verify, something to check out.

posted by Erik - 23 May 2015
Neil Thiessen
8 years, 11 months ago.

Hi Robin. Unfortunately, I don't have a K64F board to test with. If I recall correctly though, none of the Freescale boards support 16-bit frames.

The KL25 IIRC doesn't. The KL46 and all M4s (so including K64) do. If it doesn't it also should result in error message.

Another possible option is that on some settings the last bit ends up as way too short. This is related to how fast the mbed transmits the next byte: In 8-bit mode the overhead of the library could be enough to have a margin, while in 16-bit mode this is not sufficient.

posted by Erik - 01 May 2015

Is there any mechanism to ensure that the last bit is the correct length, shouldn't this be handled by the library?

posted by Robin Hourahane 01 May 2015

I don't see how the last bit could be too short, and if it is wouldn't that be a problem with the SPI peripheral itself rather than the software?

posted by Neil Thiessen 02 May 2015

My question was more aimed at Erik as I would assume that any changes would relate to the SPI driver/settings rather that the SD code.

posted by Robin Hourahane 02 May 2015
Erik -
8 years, 11 months ago.

I didn't see the comments since you don't get mails when they are placed for someone elses question :).

The (possible) problem is indeed with the SPI code/peripheral and not this library. I know it caused major issues with SPI modes 1 and 3, and also with low frequency SPI (100kHz). I don't know if at higher frequencies and longer transmission lengths it would also cause issues. Currently I actually don't think so, and I didn't test it myself yet, but still: Worth a try.

Since just my pull request which should fix those issues was accepted, can you delete your mbed library from your program and import: https://developer.mbed.org/users/mbed_official/code/mbed-src/.

At 100kHz it solved this: http://static.tweakers.net/ext/f/gAoTfuAGPXuMgtqbCm34UOJ9/full.png while for format 1/3 it solves: https://camo.githubusercontent.com/5c28baeca1299c413af9cbcb7795c4ef0e9f49bd/687474703a2f2f646576656c6f7065722e6d6265642e6f72672f6d656469612f75706c6f6164732f7a6879656e612f6672646d5f6b3634665f7370695f6d6f6465332e706e672e7061676573706565642e63652e37324e4f4b6b6b72514d2e706e67. (Nice link there). So might very well not help for you, but since it is an SPI related problem it can't hurt to try it. Otherwise when I got time I'll check 16-bit transmission with logic analyzer.

+1 Erik for this comment

posted by Martin Kojtal 04 May 2015

Tried switching to mbed-src but unfortunately it didn't solve the problem. It would be great if you could find the time to check things out the the logic analyzer.

posted by Robin Hourahane 04 May 2015

Took some time but I just checked it with logic analyzer: Using latest mbed-src at 100kHz, 1MHz and 10MHz the SPI waveform is fine in 16-bit format. So that cannot cause it.

posted by Erik - 10 May 2015