reject programs with invalid memory layout

[japaric]

it's not uncommon to get the memory.x file (which describes the memory layout of the device) wrong when you have to write it manually (e.g. the HAL doesn't provide one). The file looks like this:

MEMORY
{
  FLASH : ORIGIN = 0x00000000, LENGTH = 64K
  RAM : ORIGIN = 0x20000000, LENGTH = 48K
}

If you get FLASH wrong then probe-rs will error with a reasonable error message so that's covered.

If you get RAM wrong, however, probe-rs will say nothing (probably because it doesn't write to RAM when loading the program).

What can go wrong there is: you specify a LENGTH greater than what the amount of RAM the device has. The result is: your stack pointer (whose initial value is stored in the vector table) starts outside physical RAM so your program won't even start.

If LENGTH is smaller than the amount of RAM the device has then nothing bad happens but you end up under-using the device resources.

What we should do:

• as a first solution, check that the initial stack pointer value (we already read parts of the vector table so we may already have this value available) is within the device's physical RAM (this info is available via probe-rs; we probably already have this value as well). Error if the initial stack pointer value lies outside the range of physical RAM
• as a more thorough solution, we should consider static variables. if you are using flip link, static variables lie above the stack so even if the stack lies in a valid RAM location, static variables may lie outside RAM if you specify a wrong RAM LENGTH.
• bonus feature: print a warning if RAM LENGTH (in memory.x) is smaller than device's actual amount of RAM. This is tricky in the presence of flip-link because the last static variable may not be exactly aligned to the RAM boundary due to alignment requirements of static variables (so there may be a "gap", unused RAM, near to the upper RAM boundary). Some heuristics may need to be applied here, e.g. "if the gap is greater than 1K then likely RAM LENGTH was under specified".

[japaric]

in addition to the information that comes from probe-rs (--chip) we can also do a write random bits, readback+check operation on RAM to see if it's writable at all. The reason to do this extra check is that it's possible to specify the wrong --chip part (less or more RAM) and still be able to write a program to the target device's Flash.