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

[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:

zephyr/drivers/dma/dma_stm32_bdma.c

Lines 566 to 573 in 662b980

	/* 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:

zephyr/drivers/dma/dma_stm32_bdma.c

Lines 462 to 478 in 662b980

	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/tests/drivers/dma/chan_blen_transfer/CMakeLists.txt

Line 10 in 662b980

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:

zephyr/tests/drivers/dma/chan_blen_transfer/boards/nucleo_h743zi.conf

Lines 5 to 9 in 662b980

	# 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:

zephyr/tests/drivers/dma/chan_blen_transfer/src/test_dma.c

Lines 25 to 26 in 4180d70

	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:
  

  zephyr/tests/drivers/dma/chan_blen_transfer/src/test_dma.c

  Lines 25 to 26 in 662b980

  	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).

[mathieuchopstm]

Potential fix proposition: move tx_data and rx_data to a separate file, and relocate the whole file.

Appears to work on STM32WB0 and STM32H7, PR incoming.

[mathieuchopstm]

Fix proposed in #75895.