Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

FRDM-K22F: SPI frequency is set to 93 kHz #840

Closed
PrzemekWirkus opened this issue Jan 12, 2015 · 6 comments
Closed

FRDM-K22F: SPI frequency is set to 93 kHz #840

PrzemekWirkus opened this issue Jan 12, 2015 · 6 comments

Comments

@PrzemekWirkus
Copy link
Contributor

I've just ran few SD card tests and I can see on logical analyzer that SPI frequency (CLK) is set to ~93kHZ.
Result: SD card tests are failing for K22F:

singletest.py -i test_spec.json -M muts_all.json -P -V
Building library CMSIS (K22F, ARM)
Building library MBED (K22F, ARM)
Building library FAT (K22F, ARM)
Building project SD (K22F, ARM)
Compile: main.cpp
Link: sd
Elf2Bin: sd
Executing 'python host_test.py -d G:\ -f "C:\Work\mbed\build\test\K22F\ARM\MBED_A12\sd.bin" -p COM93 -t 15 -C 4 -m K22F'
Test::Output::Start
MBED: Instrumentation: "COM93" and disk: "G:\"
HOST: Copy image onto target...
HOST: Initialize serial port...
HOST: Reset target...
 Not in idle state after sending CMD8 (not an SD card?)
Fail to initialize card
SD: Writing ... [FAIL]
Not in idle state after sending CMD8 (not an SD card?)
Fail to initialize card
SD: Reading data ... [FAIL]
{{failure}}
{{end}}
Test::Output::Finish
TargetTest::K22F::ARM::MBED_A12::SD File System [FAIL] in 7.38 of 15 sec
Building library FAT (K22F, ARM)
Building project SD_PERF_STDIO (K22F, ARM)
Compile: main.cpp
Link: sd_perf_stdio
Elf2Bin: sd_perf_stdio
Executing 'python host_test.py -d G:\ -f "C:\Work\mbed\build\test\K22F\ARM\PERF_1\sd_perf_stdio.bin" -p COM93 -t 15 -C 4 -m K22F'
Test::Output::Start
MBED: Instrumentation: "COM93" and disk: "G:\"
HOST: Copy image onto target...
HOST: Initialize serial port...
HOST: Reset target...

SD Card Stdio Performance Test
File name: /sd/testfile.bin
Buffer size: 128 KiB
Write test...
Not in idle state after sending CMD8 (not an SD card?)
Fail to initialize card
File '/sd/testfile.bin' not opened
{{failure}}
{{end}}
Test::Output::Finish
TargetTest::K22F::ARM::PERF_1::SD Stdio R/W Speed [FAIL] in 7.43 of 15 sec
Building library FAT (K22F, ARM)
Building project SD_PERF_FHANDLE (K22F, ARM)
Compile: main.cpp
Link: sd_perf_fhandle
Elf2Bin: sd_perf_fhandle
Executing 'python host_test.py -d G:\ -f "C:\Work\mbed\build\test\K22F\ARM\PERF_2\sd_perf_fhandle.bin" -p COM93 -t 15 -C 4 -m K22F'
Test::Output::Start
MBED: Instrumentation: "COM93" and disk: "G:\"
HOST: Copy image onto target...
HOST: Initialize serial port...
HOST: Reset target...

SD Card FileHandle Performance Test
File name: testfile.bin
Buffer size: 128 KiB
Write test...
Not in idle state after sending CMD8 (not an SD card?)
Fail to initialize card
File 'testfile.bin' not opened
{{failure}}
{{end}}
Test::Output::Finish
TargetTest::K22F::ARM::PERF_2::SD FileHandle R/W Speed [FAIL] in 7.39 of 15 sec
Building library FAT (K22F, ARM)
Building project SD_PERF_FATFS (K22F, ARM)
Compile: main.cpp
Link: sd_perf_fatfs
Elf2Bin: sd_perf_fatfs
Executing 'python host_test.py -d G:\ -f "C:\Work\mbed\build\test\K22F\ARM\PERF_3\sd_perf_fatfs.bin" -p COM93 -t 15 -C 4 -m K22F'
Test::Output::Start
MBED: Instrumentation: "COM93" and disk: "G:\"
HOST: Copy image onto target...
HOST: Initialize serial port...
HOST: Reset target...

SD Card FatFS Performance Test
File name: 0:testfile.bin
Buffer size: 128 KiB
Write test...
Not in idle state after sending CMD8 (not an SD card?)
Fail to initialize card
File '0:testfile.bin' not opened
{{failure}}
{{end}}
Test::Output::Finish
TargetTest::K22F::ARM::PERF_3::SD FatFS R/W Speed [FAIL] in 7.38 of 15 sec
Test summary:
+--------+--------+-----------+----------+-------------------------+--------------------+---------------+-------+
| Result | Target | Toolchain | Test ID  | Test Description        | Elapsed Time (sec) | Timeout (sec) | Loops |
+--------+--------+-----------+----------+-------------------------+--------------------+---------------+-------+
| FAIL   | K22F   | ARM       | MBED_A12 | SD File System          |        7.38        |       15      |  0/1  |
| FAIL   | K22F   | ARM       | PERF_1   | SD Stdio R/W Speed      |        7.43        |       15      |  0/1  |
| FAIL   | K22F   | ARM       | PERF_2   | SD FileHandle R/W Speed |        7.39        |       15      |  0/1  |
| FAIL   | K22F   | ARM       | PERF_3   | SD FatFS R/W Speed      |        7.38        |       15      |  0/1  |
+--------+--------+-----------+----------+-------------------------+--------------------+---------------+-------+
Result: 4 FAIL

Completed in 36.61 sec
@PrzemekWirkus
Copy link
Contributor Author

Logical analyzer output (SD card to not send response due to low master frequency):
k22f_spi

@0xc0170
Copy link
Contributor

0xc0170 commented Jan 13, 2015

Can you please also test K64F? They share the same implementation, so this should appear for K64F also.

@Sissors
Copy link
Contributor

Sissors commented Jan 21, 2015

The same situation is on the K64F, and every single other targets, since it explicitly puts the frequency on 100kHz in the SD filesystem code initialization section: _spi.frequency(100000);

Some logic analyser tests show nothing wrong with the frequency of the SPI.

What does seem to be the issue should appear better if you put your logic analyzer at 24MHz: there is an extremely short low-time between two consecutive words: at 100kHz it is less than 100ns, while at 400kHz it is 600ns, and after that it keeps increasing. In your picture it can already be seen though.

What I think is happening that at the last rising edge the peripheral returns the read data to the mbed function. Now the peripheral still has to make a falling edge to go to its active low state. At high frequencies this means the mbed functions provide enough overhead that before the next command is sent, there is a gap between the commands. At low frequencies the peripheral waiting before it may make its falling edge is longer than the overhead of the functions. Now the moment it has a falling edge, it pretty much directly makes a rising edge again to start the next SPI command, resulting in a very tiny low period, and I think thats the problem.

Why this happens I don't know, you would think it is protected against that. But it might be solvable using all the different delay settings of the SPI peripheral. It should also appear on the K64F though.

@Sissors
Copy link
Contributor

Sissors commented May 5, 2015

This should now be also solved with above pull request, maybe @PrzemekWirkus can reverify it.

@ciarmcom
Copy link
Member

ciarmcom commented Aug 1, 2016

ARM Internal Ref: IOTMORF-300

@sg-
Copy link
Contributor

sg- commented Jan 10, 2017

Seems resolved. Please reopen if not.

@sg- sg- closed this as completed Jan 10, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

5 participants