I'm using USART0 on my SAM4E in SPI slave mode, with DMA.
A bit of background of my test... I'm trying to send a single byte of 0x00 from the slave (the SAM4E) to the SPI master. Both devices are configured to use SPi mode 0. When the SPI master sends clock signals to read data from the SAM4E, the MSB of the data is incorrect. The MISO line is normally low until the slave select signal is activated. At that point, the MISO line goes high, and when the leading edge of the clock appears, the data is sampled while the MISO line is still high.
I wasn't able to attach an image to this post (attachment quota has been reached??), but a screen capture of the SPI lines shows the problem more clearly.
Input 4 (Green) is the slave select signal
Input 2 (Cyan) is the SCLK from the master
Input 3 (Magenta) is MISO
Notice that when slave select goes low, MISO immediately goes high. This is what I'm trying to figure out. What causes MISO to go high in this case?
In this case, although I'm expecting to transfer a 0x00 from slave to master, the master is actually seeing 0x80 because of the state of the MISO line.
Any ideas what controls the level of the MISO line immediately after slave select goes low?
Discussion around product based on ARM Cortex M4 core.
2 posts • Page 1 of 1
Greetings, the only thing that springs to mind is taking a look at your init_board defs for the SPI pins in init.c. As the SPI becomes active, the pins may start with their default values? Try to define the Pin flags as OUTPUT_0 by default and see if this changes the operation? Otherwise, are you not perhaps sampling the wrong part of the full transfer, looking at an address or command byte, before the data?
Who is online
Users browsing this forum: Google [Bot] and 2 guests