Skip to content

tests: dma: chan_blen_transfer: test breakage on Nucleo-H743ZI #75676

@mathieuchopstm

Description

@mathieuchopstm

Describe the bug

(follow-up issue to #75125)

After merge of #75245, the chan_blen_transfer test now succeeds on STM32WB0 MCUs but fails on Nucleo-H743ZI.

Relevant test log extract:

===================================================================                                                                       
START - test_tst_dma1_m2m_chan0_burst16                                                                                                   
Preparing DMA Controller: Name=dmamux@58025800, Chan_ID=4, BURST_LEN=2                                                                    
Starting the transfer                                                                                                                     
E: invalid source address                                                                                                                 
E: cannot configure the dmamux. 

The invalid source address message is emitted here:

/* ensure all memory addresses are in SRAM4 */
if (channel->direction == MEMORY_TO_PERIPHERAL || channel->direction == MEMORY_TO_MEMORY) {
if (!bdma_stm32_is_valid_memory_address(config->head_block->source_address,
config->head_block->block_size)) {
LOG_ERR("invalid source address");
return -EINVAL;
}
}

where bdma_stm32_is_valid_memory_address is:
static bool bdma_stm32_is_valid_memory_address(const uint32_t address, const uint32_t size)
{
/* The BDMA can only access memory addresses in SRAM4 */
const uint32_t sram4_start = DT_REG_ADDR(DT_NODELABEL(sram4));
const uint32_t sram4_end = sram4_start + DT_REG_SIZE(DT_NODELABEL(sram4));
if (address < sram4_start) {
return false;
}
if (address + size > sram4_end) {
return false;
}
return true;
}

TL;DR: the DMA driver refuses the transfer because the source is not in SRAM4.

The regression comes from the fact that, beforehand, the .rodata and .bss segments of the test code could be relocated thanks to:

zephyr_code_relocate(FILES src/test_dma.c LOCATION ${CONFIG_DMA_LOOP_TRANSFER_RELOCATE_SECTION}_RODATA_BSS)

And indeed, the Kconfig for Nucleo-H743ZI makes use of this feature:

# Required by BDMA which only has access to
# a NOCACHE SRAM4 section. All other DMAs also
# has access to this section.
CONFIG_CODE_DATA_RELOCATION=y
CONFIG_DMA_LOOP_TRANSFER_RELOCATE_SECTION="SRAM4"

Before #75245, the test looked like this:

static __aligned(32) const char tx_data[] = "It is harder to be kind than to be wise........";
static __aligned(32) char rx_data[RX_BUFF_SIZE] = { 0 };

  • tx_buff is static const and initialized, so it goes in .rodata and gets relocated
  • rx_buff is static, not const, but uninitialized, so it goes in .bss and gets relocated
    After the patch, it now looks like this:
    static __aligned(32) char tx_data[] = "It is harder to be kind than to be wise........";
    static __aligned(32) char rx_data[RX_BUFF_SIZE] = { 0 };
  • tx_buff is static, not const, and initialized, so it goes in .data and is not relocated
  • rx_buff is static, not const, but uninitialized, so it goes in .bss and gets relocated

Expected behavior
Test should not fail.

Impact
Test breakage on Nucleo-H743ZI and potentially all boards with a Kconfig overlay setting CONFIG_DMA_LOOP_TRANSFER_RELOCATE_SECTION (i.e., mimxrt boards).

Metadata

Metadata

Labels

area: DMADirect Memory AccessbugThe issue is a bug, or the PR is fixing a bugplatform: STM32ST Micro STM32priority: lowLow impact/importance bug

Type

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions