cancel
Showing results for 
Search instead for 
Did you mean: 

H750 value line

BSant.1
Associate II

I'm starting a project with stm32h750vb. Is it really worth it? I see that people are having problems with ADC, SDMMC, I2C. Are these problems inevitable with the H7 family?

Btw, I want to make a 2 layer pcb with the h750, any advices?

11 REPLIES 11

>>Are these problems inevitable with the H7 family?

The thresholds for using these parts is higher, if you just want to click things in CubeMX and hope for working code to drop out, you'll probably be disappointed.

Have SDMMC/I2C working here.

The H7 implementation is complex, the processor is super-scaler, it has caches, and the bus matrix constrains the memories certain peripherals can use. It requires awareness.

Tips, Buy me a coffee, or three.. PayPal Venmo
Up vote any posts that you find helpful, it shows what's working..
BSant.1
Associate II

Interesting. I am familiar with stm32f103, where I made an acquisition pcb board using i2c, adc, spi (sd card), CAN. My goal with the H750 is to improve adc resolution, increase signal processing, use the sdio / sdmmc interface (optimize sample rate and data transfer) for a variety of card types, improve transmission rate on CAN- bus for data synchronization for an efficient datalogger. I know that there are other families of simpler mcus, but I find it interesting to test the limits of my acquisition system using "the best of mcus" (H7).

With f103, I had to change HAL_i2c and HAL_Can to the desired operation. With the h750 would I have to modificate the ST HAL? Or something worse?

berendi
Principal

ADC has a few quirks, parallel conversions on more than one ADC is practically unusable. Converting channels on a single ADC works fine if the analog supply is free from noise.

SDMMC works fine, maybe not at the theoretically possible highest data rate, but mind the L1 cache and the bus matrix constraints.

I2C is difficult to get right on all STM32 series, not specific to this MCU. Following the reference manual very closely usually helps.

Lots of users are having problems because they forget about the L1 cache and its implications. These problems go away when the memory buffers used by DMA and other bus master peripherals (SDMMC, USB, Ethernet) are properly configured as non-cacheable. This is specific to the F7 and H7 series, i.e. ones with Cortex-M7 core.

In general, most of the problems seen on the net seem to be related to a certain software library. Apart from the high number of bugs, it is quite poorly documented. When something doesn't work with the library, poor users are trying all sorts of hacks to make it work, sometimes it's impossible to tell whether there is a library bug, improper usage (lacking documentation, there is little agreement on what exactly proper usage is), or the feature was never meant to be supported by the library at all. Again, this is not specific to the H7 series, and the problems are not present at all when one sticks to the register interface as documented in the reference manual.

I know next to nothing of PCB design, but maybe a hint, arrange an "analog only corner" around pins 15-35 (up to 43 if using the comparators) to reduce noise on ADC.

Thanks!

Thanks!!

BSant.1
Associate II

So, L1 cache and bus matrix constrains are the main problems that users are having. Is it harder to debug the code of this part to find out where the problem is? The errata sheet of H750 helps?

The main problem is users trusting the HAL library instead of the reference manual. The L1 cache is a problem that can be solved easily, but it's the only one occuring to me which is specific to the H7 (and F7) series.

Looking at the bus matrix diagram at the beginning of chapter 2 in the reference manual should make it clear which peripheral can directly access which memories. It also gives a hint about the L1 cache behaviour.

The L1 cache is not a bug, it's a feature. It is documented the way ST usually documents related features, scattered around in the reference manual and the programming manual this time. The cache works as most other cached systems work, one must be aware what is going on behind the back of the cache. In short: DMA puts incoming data into memory, the cache doesn't pick it up, program reads stale data from the cache. Or the other way round, CPU writes outgoing data into cache, but DMA reads old data from memory.

Just read my answer in the linked post, set aside some memory for DMA/SDMMC/anything that has a bus master interface on the diagram in chapter 2, set the area as non-cacheable in the MPU (get the size and alignment right), problem solved. Stay away from the SCB_InvalidateCache mechanism, there are actually dangerous examples out there.

Berendi,

Can you elaborate a bit on your statement: "parallel conversions on more than one ADC is practically unusable"? It has significant ramifications for two of my forthcoming designs, and I would like to benefit from your insight. I'm feeling a bit nervous at the moment...

Thank you!

Regards,

Dave

Thank you very much!