Where to start STM32H7 support

ChibiOS public support forum for topics related to the STMicroelectronics STM32 family of micro-controllers.

Moderators: RoccoMarco, barthess

tridge
Posts: 141
Joined: Mon Sep 25, 2017 8:27 am
Location: Canberra, Australia
Has thanked: 10 times
Been thanked: 20 times
Contact:

Re: Where to start STM32H7 support

Postby tridge » Mon Feb 18, 2019 11:37 pm

Giovanni wrote:It is like the DMA is setup for 16bits destination, so you will get 2 bytes for each byte. Strange, the SPI driver should select 16 bits destinations only if the selected frame size is greater than 8. Verify your SPI configuration.

If I show the rx DMA config just at the point where it sets CSTART in spi_lld_exchange then I see this:

(gdb) p (void*)spip->rx->dma->stream->CR
$5 = (void *) 0x10417

(gdb) p (void*)spip->rx->dma->stream->NDTR
$8 = (void *) 0x13

The SPI config loaded into the peripheral is:

(gdb) p (void*)spip->spi->CFG1
$11 = (void *) 0x2000c007

(gdb) p (void*)spip->spi->CFG2
$13 = (void *) 0x20400000

which looks like a normal MODE0 transfer of 8 bit data with DMA.

which looks correct for a 19 byte transfer with byte transfer and memory increment. Yet this is what I see:

7f 00 7f 00 7f 00 7f 00 7f 00 7f 00 c2 00 22 00 08

a correct transfer, of 9 bytes, should give this:

7f 7f 7f 7f 7f 7f c2 22 08

(that is the ID area of a ramtron fram part)

hmm, following the suggestion from bluuu I tried polled mode. I hadn't actually noticed the spiPolledExchange() function before! I switched to using that and SPI does indeed work correctly. I had to fix some bugs in the SPIv3 spi_lld_polled_exchange() function though. Patch is attached.

So it is definitely a DMA issue, though I have no idea what it is.
Attachments
SPIv3-polled-fix.zip
(916 Bytes) Downloaded 176 times

tridge
Posts: 141
Joined: Mon Sep 25, 2017 8:27 am
Location: Canberra, Australia
Has thanked: 10 times
Been thanked: 20 times
Contact:

Re: Where to start STM32H7 support

Postby tridge » Mon Feb 18, 2019 11:58 pm

I've tested DMA on other peripherals (UARTs, ADC and I2C) and it works fine for those. It is just SPI DMA that is broken.
Very weird!

faisal
Posts: 374
Joined: Wed Jul 19, 2017 12:44 am
Has thanked: 44 times
Been thanked: 60 times

Re: Where to start STM32H7 support

Postby faisal » Tue Feb 19, 2019 1:04 am

Have you looked at the SPI bus on your saleae to confirm the extra byte being clocked? Is it real, or a software bug?

tridge
Posts: 141
Joined: Mon Sep 25, 2017 8:27 am
Location: Canberra, Australia
Has thanked: 10 times
Been thanked: 20 times
Contact:

Re: Where to start STM32H7 support

Postby tridge » Tue Feb 19, 2019 1:15 am

faisal wrote:Have you looked at the SPI bus on your saleae to confirm the extra byte being clocked? Is it real, or a software bug?

unfortunately the board is too tightly integrated to get at the pins (at least with my skills).
There is an external SPI5 connector though, and I can put a sensor on that which I can easily attach my saleae too. I'll give that a try.
thanks for the suggestion.
I'll be very surprised if the sensors are giving the extra bytes though. These are sensors I've used on lots of boards, and it happens on 3 different SPI device types (ms5611, icm20689 and FM25V02A).

User avatar
FXCoder
Posts: 384
Joined: Sun Jun 12, 2016 4:10 am
Location: Sydney, Australia
Has thanked: 180 times
Been thanked: 130 times

Re: Where to start STM32H7 support

Postby FXCoder » Tue Feb 19, 2019 1:41 am

Hi,
Could this be related to the setting of SPI CR2:TSIZE?
TSIZE is set to 0 in spi_lld_start but not set to the actual transfer size when exchange, send or receive are called.
If TSIZE is 0 then the SPI peripheral is set for an endless transaction which may cause an unexpected extra transfer?
--
Bob

faisal
Posts: 374
Joined: Wed Jul 19, 2017 12:44 am
Has thanked: 44 times
Been thanked: 60 times

Re: Where to start STM32H7 support

Postby faisal » Tue Feb 19, 2019 1:41 am

It should be replicable on an H7 nucleo board right? From your description, it seems that the problem is with the ChibiOS SPIv3 driver in DMA mode. Wish I had an H7 board lying around - would have tried it real quick for you. I know SPIv2 doesn't have this problem, I've used it on the L4, and F7.

tridge
Posts: 141
Joined: Mon Sep 25, 2017 8:27 am
Location: Canberra, Australia
Has thanked: 10 times
Been thanked: 20 times
Contact:

Re: Where to start STM32H7 support

Postby tridge » Tue Feb 19, 2019 1:50 am

faisal wrote:It should be replicable on an H7 nucleo board right?.

no, it isn't.
I have 3 H743 boards:
- one with HSE at 24MHz
- one with HSE at 16MHz
- one with HSE at 8MHz (the nucleo)
The problem only happens on the board with a 16MHz HSE. It is bizarre, as I use the clock tree to keep the peripheral and cpu clocks the same on all boards.
I should also note that the 16MHz board uses a BGA part, the others use LQF.

tridge
Posts: 141
Joined: Mon Sep 25, 2017 8:27 am
Location: Canberra, Australia
Has thanked: 10 times
Been thanked: 20 times
Contact:

Re: Where to start STM32H7 support

Postby tridge » Tue Feb 19, 2019 2:36 am

FXCoder wrote:Could this be related to the setting of SPI CR2:TSIZE?

nice idea. I just tried setting TSIZE in spi_lld_exchange(), and strangely enough I always end up with zero bytes in the receive buffer (ie. all bytes are zero).
I suspect the issue may be in the order of setting the various SPI and DMA config registers. It may rely on a very specific ordering to work reliably.
Looking at sthal, I can see that ST does set TSIZE, but sets up the registers in a very different order.

tridge
Posts: 141
Joined: Mon Sep 25, 2017 8:27 am
Location: Canberra, Australia
Has thanked: 10 times
Been thanked: 20 times
Contact:

Re: Where to start STM32H7 support

Postby tridge » Tue Feb 19, 2019 6:01 am

faisal wrote:Have you looked at the SPI bus on your saleae to confirm the extra byte being clocked? Is it real, or a software bug?

I now have SPI5 hooked up to an external port, with a MPU9250 IMU attached, and I've got a Saleae trace
Image
The query I'm sending is a read of register 0xF5 for 2 bytes. It should return 0x71 0x00, but actually returns 0x00 0x71. The above trace shows the sensor is correctly returning 0x71 0x00, so the issue is definately inside the H743.
I included the analog capture (terrible bandwidth as this is an older Saleae pro) so you can see it isn't an issue with the signal levels.
This sensor supports both mode0 and mode3. The result is the same with both.
I've also tried using the MIDI settings to insert delays between the bytes in the clocking, and that doesn't help (it does insert the delay, but I still get the 0 bytes inserted)

User avatar
Giovanni
Site Admin
Posts: 14444
Joined: Wed May 27, 2009 8:48 am
Location: Salerno, Italy
Has thanked: 1074 times
Been thanked: 921 times
Contact:

Re: Where to start STM32H7 support

Postby Giovanni » Tue Feb 19, 2019 7:59 am

It could be a defective part, it is strange that only one of those boards shows this problem.

Could you test another board of the same kind?

Giovanni


Return to “STM32 Support”

Who is online

Users browsing this forum: No registered users and 17 guests