malikabhi05
commented
7 years ago Hi @maxdos64 , so I tried to run your code as is and ran into an error with pinmuxing. This occured because you were missing a flag CONFIG_PINMUX_DEV_QMSI, once i added that and set it to "y", I was able to run your code and got the following output:
Running Spi Test 5 Pattern: 0x0102030405060708 Result: 0x0102030405060708 Test Done
Let me know if this is the expected output or not. Moving on to the frequency part, I totally agree that a frequency setting of 0 will give a system crash, that is because there is no guard around the frequency divider calculation. Thanks for pointing this out, I will open a PR soon with this change.
Also, I don't think the frequency doesn't change at all, I tried your code with 3 different frequencies and got the above mentioned output on all of them. The frequencies I tried were 16MHz (came with the code), 400 KHz and 80KHz. For 400 KHz I saw on my Logic Analyzer that the CLK period was 2.5 us and for 80 KHz it was 12.5 us, which seems about right to me. For 16 MHz, I got a time of about 60 ns or so on my LA.
About the last part of your comment (pattern of the input changing), the output is 0xFF (255). If you look at the code, you have an if statement in your code when you print the "pattern":
printf("Pattern: 0x"); for(int i = 0; i < length; i++) { if(result[i] < 15) printf("0"); printf("%X", pattern[i]); } printf("\n");
You are using that if statement to check the result and printing the pattern accordingly. Since after disconnecting the result is always 0xFF, this if condition won't let you print the "0". Perhaps this should actually be if(pattern[i] < 15), since you're printing the pattern??
Sorry for the late reply, let me know if this answers your questions.
the attached testcode shows weird behaviors when varying the settings. Its meant to be run on an arduino101 with looped miso mosi
A frequency setting of zero gives a system crash a frequncy setting of several 100 mhz works fine At all frequency seems not to change no matter what value is put in there
The calculation function mraa_spi_frequency uses hardcoded sys clock value
Really weird: when disconnecting the loop cable the reading of course becomes 0xFF.. or 0x00 but it seems like the printout of the input pattern (after the failed write) changes -> memory corruption seems possible spi_test.zip