a-lunev commented on pull request #3958: URL: https://github.com/apache/incubator-nuttx/pull/3958#issuecomment-864997606
> @a-lunev - Why is this needed when stm32_dmapreflight already excludes it? Hi David, stm32_dmapreflight() depends on the CONFIG_STM32H7_SDMMC_IDMA option that as I understand should not do, because IDMA is still in use not depending on the option. Also stm32_dmapreflight() is invoked olny if CONFIG_DEBUG_ASSERTIONS option is enabled. If my understanding is correct, concerning namely SDMMC1 IDMA, stm32_dmapreflight() is useful for debug purposes to check if IDMA is trying to access not allowed memory regions like SRAM123 and SRAM4. This can be caught only if CONFIG_DEBUG_ASSERTIONS option is enabled. In a normal build CONFIG_DEBUG_ASSERTIONS option is not enabled. How then the system should be prevented from the IDMA access failure? On another hand, if CONFIG_DEBUG_ASSERTIONS option is enabled and the assert triggered, what the further developer actions should be in this particular case with SDMMC1 IDMA? As I understand, normally there are two possible options: - either to exclude SRAM123 and/or SRAM4 from the heap allocation; - or to use SDMMC2 instead of SDMMC1 as SDMMC2 does not have the access limitation. Please let me know what do you think. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
