STM32L4 and multiple RAM sections

[VilNeo]

Describe the bug

Hello,

many (every?) STM32L4 devices provide two SRAM regions (SRAM1 and SRAM2) which can be accessed from 0x20000000 continuously. This makes it possible to use e.g. 64k for STM32L432KCU or 40k for STM32L412KBU.

Unfortunately, with the commit the available SRAM regions switched from (SRAM1+SRAM2) to just SRAM1.

This may lead to some problems:

1. I was not aware of this change (still using e.g. 64k RAM for STM32L432KCU in memory.x) and my program has been behaving strangely. Just the INFO message when using probe-run gave me the right clue. When using probe-rs I get no info, warning or error at all. So I would prefer to get a descriptive error message maybe even with program exit here.
2. Is there an approach for dealing with multiple RAM-sections with probe-rs? If not, I would prefer to have the full SRAM1+SRAM2 available.

To Reproduce Steps to reproduce the behavior:

1. Use the defmt app-template.
2. Use either stm32l4 = {version="0.15.1", features = ["stm32l4x2"]} or stm32l4xx-hal = {version = "0.7", features = ["stm32l432"]}
3. Use memory.x with following content:

MEMORY
{
  /* NOTE K = KiBi = 1024 bytes */
  /* TODO Adjust these memory regions to match your device memory layout */
  FLASH : ORIGIN = 0x8000000, LENGTH = 256K
  RAM : ORIGIN = 0x20000000, LENGTH = 64K /*SRAM1 + SRAM2 = 48k + 16k for STM32L432KCUx*/
}

Expected behavior

1. Raise an error, when the flashing image requires more space than defined in probe-rs.
2. Increase the available RAM to SRAM1+SRAM2 or make it available with a dedicated configuration.

Desktop (please complete the following information):

• Arch Linux
• probe-rs 0.21.1
• defmt 0.3.5
• rustc 1.73.0

Of course, I could change them as well resulting in a pull request. But I would like to have the previously mentioned points discussed beforehand.

Thank you very much and best regards Alex

[Tiwalun]

My suspicion here is that this is either an RTT or defmt bug. Those parts of the code use the memory definition to read or write some data. The main probe-rs code does not really care about the RAM, it only needs a small amount while flashing, but this doesn't matter when the firmware is running.

Have you tried changing the target file to use only a single, larger RAM region, and does that solve your issue?

[Tiwalun]

The target configuration file is auto-generated, so the RAM is probably just not specified in the file that ST provides. Adding the correct region there should solve your problem.

[Tiwalun]

Cause for this bug seems to be:

• The read_c_string function only reads the string if it's located in a known memory region:

  https://github.com/probe-rs/probe-rs/blob/737edeadea820b68de1eb0cdb9292605730a3b67/probe-rs/src/rtt/channel.rs#L361-L396

• This function is used to retrieve the name of the RTT channel, but it fails because the string is not in a known memory region.

• The name of the channel is used to determine the format, but because retrieving it failed, the channel is assumed to use the String data format.

• Because of this, the code tries to interpret the defmt data as a String, which fails.

[VilNeo]

Thank you very much. Indeed, I remember, that the RTT channel was not named properly. Adding another RAM-entry fixed the problem.

I will add the missing entries within the next days.

Thank you for your help!

[Yatekii]

probe-run places a canary on the stack which triggers this. We could do the same.

[VilNeo]

Good point. In fact, the canary check in probe-run gave me the hint, that the wrong defmt output may be related to the probe-rs target definitions. I will try to consider this in my future PR as well.

[VilNeo]

I will take care of the canary feature in a dedicated PR.

[Yatekii]

Thanks a lot!