Skip to content
This repository has been archived by the owner on Jan 3, 2023. It is now read-only.

SPI Transceive -> weird behavior #22

Open
maxdos64 opened this issue Oct 11, 2016 · 1 comment
Open

SPI Transceive -> weird behavior #22

maxdos64 opened this issue Oct 11, 2016 · 1 comment

Comments

@maxdos64
Copy link
Contributor

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

@malikabhi05
Copy link
Contributor

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.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants