STM32H743BI bootloader saves data to RAM.

[ZSade.1]

hi

my software programmer is trying to set DMA on RAM, he passed the start address of the DMA RAM buffer from 0x20000000 to 0x20004100 and we got the error in the attached picture.

he said that the LINKER of the CODE demands to define the pointers to the RAM, to prevent from other compiling commands takes that RAM area.

the bootloader still refuses to write to RAM also in address 0x20004100 which was supposed to be accessible.

please advice

------------------------------------------------------------------------------------------------------------------------

Hi,

According to the application note AN2606 (Cf. Table 113), the bootloader is using 20 Kbyte starting from address 0x24000000. Thus

you can only start programming at address 0x24005000 to 0x2407FFFF. We can also find at table 174 the only accessible memory addresses:

 0x20004100 - 0x2001FFFF

0x24005000 - 0x2407FFFF

 Best regards,

 Pape

------------------------------------------------------------------------------------------------------------------------

This is the answer for my last question:

------------------------------------------------------------------------------------------------------------------------

Dear Zvi Sade,

Below case has been updated.

Case#: 00179761

Subject: STM32H743BIT6 BOOT LOADER fail to communicate via USART1

Description:

Here is my response:

I am using RAM_D1 because USART DMA can only write data to this section.

If i use SWD/JLINK, i successfully writes to RAM_D1 with no issues.

Why bootloader fail to write something to RAM_D1 section?

  Please visit ST Customer Support Portal for further information.

Link to access the case:

https://community.st.com/s/case/5003W00000PV7FiQAL

Best regards,

ST Customer Support

ref:_00Db0000000YtG6._5003W00000PV7Fi:ref

------------------------------------------------------------------------------------------------------------------------

[Tesla DeLorean]

What exactly are you looking for here?

The SWD doesn't access via code execution

The System Loader runs from ROM, and it uses some of the SRAM for it's own purposes.

Do a disassembly, and determine the threshold conditions for the memory check.

Why are you pushing data into RAM here anyway? You're writing a hex file describing 0x08000000, if STM32 Programmer is reporting correctly, can't you just unpack what you need into RAM? Why is it described in the .HEX ?

[ZSade.1]

Hi,

in STM32H7, in order to user the DMA for USARTS, the DMA is controlling the D1/D2 memory regions.

therefor I need to locate the DMA rx buffers in these regions (2400000).

(https://community.st.com/s/article/FAQ-DMA-is-not-working-on-STM32H7-devices)

I am not forcing anything to be written during flash.

there is no problem with flashing the hex file as is via SWD. just the bootloader has problems "flashing" ROM...

my linker script section is:

MEMORY

{

DTCMRAM (xrw)   : ORIGIN = 0x20000000, LENGTH = 128K

RAM_D1 (xrw)   : ORIGIN = 0x24005000, LENGTH = 492K

RAM_D2 (xrw)   : ORIGIN = 0x30000000, LENGTH = 288K

RAM_D3 (xrw)   : ORIGIN = 0x38000000, LENGTH = 64K

ITCMRAM (xrw)   : ORIGIN = 0x00000000, LENGTH = 64K

FLASH (rx)   : ORIGIN = 0x8000000, LENGTH = 2048K

}

 /* User_heap_stack section, used to check that there is enough RAM left */

 ._user_heap_stack :

 {

  . = ALIGN(8);

  PROVIDE ( end = . );

  PROVIDE ( _end = . );

  . = . + _Min_Heap_Size;

  . = . + _Min_Stack_Size;

  . = ALIGN(8);

 } >DTCMRAM

 .d1_block :

 {

  . = ALIGN(4);

  *(.d1_block)     /* .data sections */

 } >RAM_D1

 .d2_block :

 {

  . = ALIGN(4);

  _sd2_block = .;    /* create a global symbol at data start */

  . = ALIGN(4);

  *(.d2_block)     /* .data sections */

  _ed2_block = .;    /* define a global symbol at data end */

 } >RAM_D3

  /* Ethernet Modification start */

 .lwip_sec (NOLOAD) :

 {

  . = ABSOLUTE(0x30040000);

  *(.RxDecripSection)

  

  . = ABSOLUTE(0x30040060);

  *(.TxDecripSection)

  

  . = ABSOLUTE(0x30040200);

  *(.RxArraySection)

 } >RAM_D2

 /* Ethernet Modification end */

and the code is located at D1:

uint8_t __attribute__ ((section (".d1_block"), aligned (4))) protocol_rx_buffer[128];

[Pavel A.]

Try to make .d1_block (NOLOAD) just as .lwip_sec.

Will this solve the loading problem?

​

If yes : your script still does not look right because the initialized data section is missing.

Take a link script from any Cube-generated example (even without ethernet) and compare.

[ZSade.1]

the "NOLOAD" did the job

thanks !