cancel
Showing results for 
Search instead for 
Did you mean: 

STM32F3 discovery: SPI in 16 bit mode???

re.wolff9
Senior
Posted on June 30, 2013 at 21:49

Hi,

I'm sending data on the SPI interface. This seems to work a bit. The most important difference from what I expected is now that I want to put an 8bit value in the DR register, and I end up with 16 bits being clocked out. I've set ''ds[3:0]'' to the value 0x07: 8 bit datasize. For debugging my app allows me to dump the register contents:

40003800 0000007c 00000704 00000403 0000ffff
40003810 00000007 00000000 00000000 00000000
40003820 00000002 00000000 00000000 00000000

The ''7'' in 704 are the ''data size'' bits if I'm correct. dataregister reads as 0xff, as my miso is currently still ''stuck at 1'' (at least the logic analyser agrees with the stm32). The other problem I'm seeing is that I can't find a way to ''wait for transmission to complete''. When I activate-SS/send/wait-for-completion/deactivate-SS, I always see a pulse on the SS line shorter than a bit. For now I've got just a ''delay()'' in there. Works for now, but it would be nicer if something like: while (!(SPI_SR(SPI2) & SPI_SR_TXE)); would work. Ok! Got it. Fixed that one! Apparently I started out with something in the RX fifo, so when I transferred something, I had immediately data to get from the RX fifo. Clearing the FIFO before the SPI transfer causes the wait-for-RX-data to actually wait.... That leaves the ''why do I get 16 bits'' question....
9 REPLIES 9
re.wolff9
Senior
Posted on July 01, 2013 at 10:31

re.wolff9
Senior
Posted on July 01, 2013 at 10:33

Dear ST.

It took me a few hours to write a detailed reply/update/new question.

The forum software then dumps me into a ''fresh'' reply screen, with ''back'' going to a similarly clean screen.

PLEASE fix your forum software not to dump my messages. Thankyou.

frankmeyer9
Associate II
Posted on July 01, 2013 at 10:43

PLEASE fix your forum software not to dump my messages. Thankyou.

 

 

wolff.roger

 

  Posts : 4

 

Welcome to the club.

Albeit this forum software changed recently (slightly), the inclination to crash your posts is still the common denominator. What do you expect by something backed with M$ SharePoint ?

Most often you can hit the ''back'' button of your browser, to save your post either to an external editor, or copy it over directly to another browser-tab, where you open the forum again ...

Trying to re-send it from that first tab will fail again with 99.99% probability.

re.wolff9
Senior
Posted on September 27, 2013 at 17:23

IIRC, the library I'm using defines the register as a 16-bit register. The STM32F3 (in contrast to the STM32F1 where the library was developed for first) looks at the data-transfer-size to determine the amount of data to shift into the FIFO..... Casting the register definition to an unsigned char before doing the assignment causes one byte of data to be clocked into the fifo and out of the SPI port as expected. 

pl
Associate II
Posted on October 27, 2014 at 23:30

Thanks Roger - had the same experience -> desperation -> your findings -> nok

was using CubeXL which generates code; performs too slow  so I had to program registers directly, causing the 16bit problem (at least on SPI1):

Initializing CR2 with 0x00001700 (the '7'   indicates 8bit data length) but sends 16 (!) clock cycles. The slave chip answers correctly after 8 clock cycles with one byte. The answer is available from data register DR input. But: if I send a second byte to transfer one more byte another 16bit clock is generated so I have to do tedious byte calculation to recover the received bytes from the slave device.

Seems to be a definite bug in the STM32F303VC Chip or maybe some description has changed.

Trying to send 4 bits of data yields 8 clock cycles, but the data shifted out is only 4 bit and thus generates errors.

Any suggestions - or a real bug?

pl
Associate II
Posted on October 27, 2014 at 23:37

hi fm,

your hint helped.

Maybe it is not politically correct to ask for kicking web responsible heads, first one, then two, ... then 1001 and then a Linux guy remains who finally is able to set up a really working forum. Others work fine, but I never found a M$ one working too.

Took me lots of tries to post an answer.

If this keeps on I think about changing to ti ARM based micro controllers.  😉

(a pity, I like the STM32 series)

pl
Associate II
Posted on October 27, 2014 at 23:48

... no chance:

SPI1->DR = (uint8_t)(regAdr | 0x80);

still pushes 16 bit clock cycles out. regAdr was already defined as uint8_t;

Uwe Bonnes
Principal II
Posted on October 29, 2014 at 11:45

... no chance:

SPI1->DR = (uint8_t)(regAdr | 0x80);

still pushes 16 bit clock cycles out. regAdr was already defined as uint8_t;

Try

*(uint8_t *)&base->DR = (uint8_t)(regAdr | 0x80);

B.t.w: The forum software is a PITA :(

tomas
Associate
Posted on September 30, 2015 at 09:10

Thank's very much for this thread.

This solved my issue.