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 » Sun Mar 10, 2019 12:08 pm

Giovanni wrote:The SPI driver should allow for mixed DMA and non-DMA operations, is leaving those 2 bits enable a problem? DMA channels are disabled. It is not a problem apparently for other SPI implementations.

you're right, it works fine to leave those enabled, and that means we can mix DMA and non-DMA.

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 » Sun Mar 10, 2019 12:10 pm

So just that synchronization loop is required, good.

Giovanni

pkocmoud
Posts: 1
Joined: Thu Mar 14, 2019 12:08 am
Been thanked: 1 time

Re: Where to start STM32H7 support

Postby pkocmoud » Thu Mar 14, 2019 12:22 am

Hi Giovanni,

In the file: os/hal/ports/STM32/STM32H7xx/hal_lld.h Line 1227, should this test include both the STM32H743 and STM32H753 to require STM32H743_MCUCONF be defined or should it be broken into separate tests for the STM32H743 and STM32H753?

Maybe the STM32H753 processors were to be supported with the STM32H743_MCUCONF?

In my hwdef.dat, I defined my processor as "MCU STM32H7xx STM32H753xx" and modified the test as I mentioned above and it now compiles fine.

Patch is shown here: https://github.com/ArduPilot/ChibiOS/co ... 03c383e0e2

Thank you for your time!

Phil

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 » Sun Mar 17, 2019 9:07 am

Hi,

The modified polled exchange looks like this:

Code: Select all

uint32_t spi_lld_polled_exchange(SPIDriver *spip, uint32_t frame) {
  uint32_t dsize = (spip->spi->CFG1 & SPI_CFG1_DSIZE_Msk) + 1U;
  uint32_t rxframe;

  spip->spi->CR1 |= SPI_CR1_CSTART;

  /* wait for room in TX FIFO.*/
  while ((spip->spi->SR & SPI_SR_TXP) == 0U)
    ;

  /* Data register must be accessed with the appropriate data size.
     Byte size access (uint8_t *) for transactions that are <= 8-bit etc.*/
  if (dsize <= 8U) {
    /* Frame width is between 4 and 8 bits.*/
    volatile uint8_t *txdrp8 = (volatile uint8_t *)&spip->spi->TXDR;
    volatile uint8_t *rxdrp8 = (volatile uint8_t *)&spip->spi->RXDR;
    *txdrp8 = (uint8_t)frame;
    while ((spip->spi->SR & SPI_SR_RXP) == 0U)
      ;
    rxframe = (uint32_t)*rxdrp8;
  }
  else if (dsize <= 16U) {
    /* Frame width is between 9 and 16 bits.*/
    volatile uint16_t *txdrp16 = (volatile uint16_t *)&spip->spi->TXDR;
    volatile uint16_t *rxdrp16 = (volatile uint16_t *)&spip->spi->RXDR;
    *txdrp16 = (uint16_t)frame;
    while ((spip->spi->SR & SPI_SR_RXP) == 0U)
      ;
    rxframe = (uint32_t)*rxdrp16;
  }
  else {
    /* Frame width is between 16 and 32 bits.*/
    spip->spi->TXDR = frame;
    while ((spip->spi->SR & SPI_SR_RXP) == 0U)
      ;
    rxframe = spip->spi->RXDR;
  }

  spip->spi->CR1 |= SPI_CR1_CSUSP;

  return rxframe;
}


My problem is that I don't understand under which condition the TX FIFO is not empty on entry, all SPI operations synchronize of received frames, if you receive a frame then it means that you also transmitted one and the TX FIFO needs to be empty.

I committed this change on trunk anyway.

Giovanni

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 » Sun Mar 17, 2019 9:12 am

pkocmoud wrote:In the file: os/hal/ports/STM32/STM32H7xx/hal_lld.h Line 1227, should this test include both the STM32H743 and STM32H753 to require STM32H743_MCUCONF be defined or should it be broken into separate tests for the STM32H743 and STM32H753?

Maybe the STM32H753 processors were to be supported with the STM32H743_MCUCONF?

In my hwdef.dat, I defined my processor as "MCU STM32H7xx STM32H753xx" and modified the test as I mentioned above and it now compiles fine.


I think that mcuconf.h files should list all compatible platforms, so define both STM32H743_MCUCONF and STM32H753_MCUCONF. See how L4 mcuconf.h files do for an example.

I made this change both in trunk and in 19.1.x.

Giovanni

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 Mar 18, 2019 2:24 am

Giovanni wrote:My problem is that I don't understand under which condition the TX FIFO is not empty on entry, all SPI operations synchronize of received frames, if you receive a frame then it means that you also transmitted one and the TX FIFO needs to be empty.

I can re-test it if you like. I see what you mean about why it shouldn't be needed.
I don't use polled any more, but I can enable it again for a test

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 » Mon Mar 18, 2019 8:32 am

Thanks, that would be helpful, try to do a DMA transfer followed by a series of polled transfers then another DMA transfer (with and without the change).

Giovanni

User avatar
alex31
Posts: 374
Joined: Fri May 25, 2012 10:23 am
Location: toulouse, france
Has thanked: 38 times
Been thanked: 61 times
Contact:

Re: Where to start STM32H7 support

Postby alex31 » Mon Apr 29, 2019 1:44 pm

Hello,

looks like H7 support will become complicated.

As I have read here, https://www.eevblog.com/forum/microcontrollers/stm32h7-series-revision-beware-of-the-changes!/,
new revisions of H7, while having the same part number, will be software incompatible with firsts versions ...

finally, i'm glad to have wait before jumping into it :-)

Alexandre

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 » Mon Apr 29, 2019 5:44 pm

Hi,

Interesting, thanks for the info. I don't understand why a new revision instead of a new part number, some of those are real changes and also new features. We should also check the errata going from Y to V, we could have surprises there too.

I think the best option is to add a configuration switch and handle everything at compile time, doing checks at runtime would be a lot heavier.

Giovanni

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

[patch] unexpected error interrupt on i2c on H743

Postby tridge » Fri Jul 19, 2019 7:21 am

Hi Giovanni,
We've been happily using the H7 port for a long time now with no issue, but hit an interesting one today. I got a reproducible fault when doing a 32 byte transfer on I2C on a I2C peripheral on H743 that is in STOP state. At the time it happens there is no DMA assigned to the peripheral, so it faulted when it tried to disable a NULL DMA object. When the error happens the ISR register is 0x8101, which indicates a bus error. The device had NAKed the 32 byte read after 30 bytes, and the ArduPilot I2C driver issues a retry. The device again NAKed after 30 bytes, and then ChibiOS faulted when it gave up and released the DMA, then the ISR arrived.
I attach a patch that fixes it. I decided to add the check on I2Cv1 and I2Cv2 as well, just in case the same thing can happen.
Note that we use DMA sharing extensively in ArduPilot, so when an I2C peripheral is in STOP state it may not have a DMA channel. We need this even on H7 where the DMA is really flexible as we just have so many peripherals we're using.
I am wondering if a better fix is to protect dmaStreamDisable() everywhere against a NULL value for the stream pointer. Could there be other similar assumptions lurking in other peripheral drivers that aren't true when using DMA sharing?
Cheers, Tridge
Attachments
0001-I2C-ensure-we-never-disable-a-null-DMA.patch.zip
(1.19 KiB) Downloaded 155 times


Return to “STM32 Support”

Who is online

Users browsing this forum: No registered users and 17 guests