v0.24: Flashing is broken with j-link on AT32F437VMT7

[skibon02]

v0.24: Flashing is broken with j-link on AT32F437VMT7

[skibon02]

I've just got it working witn --disable-double-buffering option.
[UPD] flashing process done but fails to run, core halted

[bugadani]

Maybe we have incorrect memory regions for this chip, too. Do you have a datasheet for it?

[skibon02]

yes, datasheet and reference manual are avaliable here
(registration not required)

[skibon02]

[skibon02]

Here are values for flash_properties struct:

[skibon02]

Looks like AT32F4_Series.yaml wasn't changed between 0.23 and 0.24 versions of probe-rs

[bugadani]

THe problem is that these chips have user-configurable memory layouts. This issue must have started happening when we moved the flash algorithm stack to the end of memory. This can probably be fixed if we limit the stack size these devices use for flashing.

[bugadani]

I think this issue can be solved by specifying data_load_address for these targets. The reason: we place data at the end of the memory, but we don't know if we can actually use that memory. However, we place the stack before the memory, so if the target forces data_load_address inside the first 128K, everything should be placed in the first 128K which should be safe RAM.

[bugadani]

As I don't have one of these devices, please test #2561 for me.

[skibon02]

Thanks for your help on this issue!
I've tested your fork with AT32F437VMT7 and it does indeed fix the flash programming issue.

[skibon02]

Is IRAM1 range used for anything other than default data_load_address calculation?

In yaml file the maximum possible RAM range is specified, but not default one, and there is a high probability for mismatch of range.end of IRAM1 and actual end of RAM on MCU. For example, AT32F437 is marketed to have 512kB of RAM, but it is true when you manually reprogram user system data to select this mode. Default mode used in most cases includes only 384KB of RAM making accesses beyond that incorrect.