[feature] ST-Flash's --reset option & F4 DMA registers cleaning

[mcoquelin-stm32]

Hi,

I wonder whether we should always reset the devices, i.e. make the reset option a default one.
Doing this, I guess we could get rid of the DMA registers cleaning on F4?

Just let me know if you are ok on the principle, and I will propose a patch.

Thanks,
Maxime

[xor-gate]

Hi Maxime @mcoquelin-stm32,

I'm planning for v2.0.0 to rewrite/fixup the commandline argument parser. For which tool do you want to implement this? Probably we should also add a commandline switch then.

[mcoquelin-stm32]

Hi Jerry,

That is a good idea:
Note that I have developed an external memory loader based in Texane (https://github.com/mcoquelin-stm32/stlink/blob/external_loader/extloader/main.c). I allow to re-use external loaders from ST's STLink Utility to read/write external NOR and NAND.
For this implementation, I have use standard's getopt to parse parameters.
Feel free to comment it on my branch if you see any improvements that could be done, and don't hesitate to pick some code from this example.

That said, I'm not sure to understand your question:

For which tool do you want to implement this?

I initially created this ticket because I didn't see any advantage not to reset the chip before programming it.
And in some cases, clearing DMA is not enough.
I have for example a case where I remap the SDRAM bank 0 in 0x0 on STM23F429, by configuring SYSCFG_MEMRMP register.
In this case, if not using --reset option, the subsequent flash programming fails.
There is so much configurations that could lead to such problems, that I think that --reset shuold be the default. Maybe having a --noreset option would make sense if any application.

What is your view?

Regards,
Maxime

[xor-gate]

I totaly agree with the reset is default on programming and scrubbing the DMA. We should go with --noreset option then for v2.0.0 (@texane what do you think?). Would you like and have time to contribute when I have reworked the argopt parsing with a different implementation?

For the external loader it would be nice to have it merged for texane/stlink but needs to be rebased to latest master. And I would better see this merged after v2.0.0 because it would have some big impact on the codebase (refactoring et al). Probably we should create a seperate feature/issue for the external loader which is related to this issue (Quad SPI NOR flash): #412

@mcoquelin-stm32 The external loader's address range is limited to 32-bit (so no F746G-discovery programming). Is this a bug?