STM Flash Loader support for STM32F423 CPU missing

[jasonforest9]

Posted on July 24, 2017 at 20:37

Hello,

The current version 2.8.0, and the pre-release version V2.9.0RC4 floating around in the forum, do not support the STM32F423 CPU. There is no map file for this CPU. Is there an updated pre-release of the program that you can share with the support for this CPU?

Note: Even though we don't use the F413 CPU, it's in the same family as the F423, and support for this CPU is not present as well.

Thanks

[STOne-32]

Posted on July 24, 2017 at 22:58

Dear

Forest.Jason

‌,

Our moderators will share with you a pre-release version V2.9.0 by Wednesday (CET), It was delayed to public to this summer.

Cheers,

STOne -32

[Amel NASRI · Accepted solution]

Posted on July 26, 2017 at 12:59

Hi

‌,

As promised by

‌, you find attached a new RC of the version 2.9.0 of the STMFlashLoader Demo.

Please use it and confirm if recently added devices are successfully supported. If you are facing any issue with this version, don't hesitate to report it here.

-Amel

________________ Attachments : STMFlashLoader Demo_V2.9.0RC8.zip : https://st--c.eu10.content.force.com/sfc/dist/version/download/?oid=00Db0000000YtG6&ids=0680X000006HyZ1&d=%2Fa%2F0X0000000b9T%2FmCkznYRmoe94l8jEv9qd7j5T0aXFQvS_..GOCuWxV00&asPdf=false

[STOne-32]

Posted on July 26, 2017 at 17:36

Dear

Forest.Jason

‌,

First, Thanks to try our Release candidate RC8 of V2.0.9 and valuable time spent. Here are my swift answers :

1) All Screenshots : S1,S2,S3, S4 are as expected :)

2) The Automatic selection will work only on STM32F1 series, you need to select then the correct map file in the combo box. same as all STM32 series, except F1.

3) STM32F413/F423 are same for the Boot-loader thru the UART, we will update the names in the official version , Thanks !

4) BID : Do not care about it, it should be a limitation, will be mentioned in our next AN2606 and in the known limitation in the version.txt file.

5) Erase : Just increase the Timeout in the first GUI to 90 seconds as example. this product embeds 1.5MBytes of flash and erase time is exceeding the 20 seconds. but it works.

Cheers,

STOne-

[jasonforest9]

Posted on July 26, 2017 at 16:55

Hello,

I have attached four images describing what is happening with this RC8.

Image S1: The CPU type is not automatically detected, like I have seen with other CPUs like the F The PID and Version show up but the BID says NA.

Image S2: If I check the Target pull down, it at least filtered to the right series of CPU. I see that it only shows the F4 I checked the map file directory and there are only F413 files, and not F4 This may be intentional since the only difference is the AES in the F4 But it may prevent the target from being automatically selected as a F4 Each time I restart the program, I need to select the CPU, which was not the case with the F

I ended up selecting the F4_13_1536K. It populates the BID as I am not sure what BID is, but this field changes between 15 and 8.0, depending if the flash is empty or not. Empty shows 15, data shows 8.0.

Image S3: If I try to do a full erase, it gives me a failed message after 20 seconds. During the 20 seconds, the progress bar stays at 0%. But the chip does get erased, at least partially, since my code no longer runs after a reset. So there is an issue with the erase.

Image S4: If I try to program the board (without an erase first in the same step), it does program the flash and the code runs properly. If I select the option to erase only the necessary pages, this works also. If I add the option to verify after download, the verification works.

So to resume the issues:

- The exact F423 is not automatically detected by the flash loader application

- The full erase gives an error after 20 seconds. This is for both the radio button 'Erase>All' and the 'Download to device>Global Erase' option.

________________ Attachments : Pics.zip : https://st--c.eu10.content.force.com/sfc/dist/version/download/?oid=00Db0000000YtG6&ids=0680X000006HyYw&d=%2Fa%2F0X0000000b9S%2F4AxAEVjOQt6dYtk9X6SF4eM3otIro1N1jOdzisexLrw&asPdf=false

[jasonforest9]

Posted on July 26, 2017 at 18:30

Hello,

Ok for all you say. I increased the timeout to 20 seconds and it passes the erase option.

We previously noted that the F412 was much slower to erase vs the F103. Our F103 had 768K of flash and the F412 had 1024K. For the F103 we were able to keep the timeout to 1 second and everything worked fine. But on the F412, with 50% more flash, the timeout needed to be set to at least 10 seconds for the full erase (900% increase). The F412 was running at 3V, so it should be using 32-bit erase and program operations. 

Now our F423 has more Flash, so the timeout increases. It has 50% more than the F412 we used, but the timeout increases from 10 to 20 seconds (100% increase). The F423 is running also at 3V.

Questions: Is STM flash loader defaulting to 8-bit erase and program operations?

Does the F423 really take 22 seconds maximum vs. 40ms maximum for the F103? This is a 245-fold increase in erase time for only 2-fold increase in memory size. If it is simply due to architecture of the F4 series, maybe consider improving this in future revisions. For manufacturing, this is a huge hit in overall production time when using the bootloader in this method to erase the flash.

Lastly, I submitted an improvement to our rep a while ago for the flash loader because of these long timeouts that are needed now for the F4 CPUs. I will pass it on to you since you are in direct contact with development of this application.

I highly suggest that for the next revision of the Flash Loader that you add an extra field for timeout on the first screen; One timeout to wait for initial connection, and another for a timeout related to all other instructions. This way you don’t wait a long time just because it can’t get a response from the 0x7F query. (Example: If I set the timeout to 20 seconds, it takes the full 20 seconds to fail just because it did not get a response to 0x7F. This query takes less than one second and the user should not have to wait the duration of the global timeout).

Thanks

[jasonforest9]

Posted on July 26, 2017 at 20:49

Thanks. I will consider the original question answered.

We will try the command line for the faster speeds.

[STOne-32]

Posted on July 26, 2017 at 20:07

Dear

Forest.Jason

‌,

Thanks for the hint to manage two different timeouts. one for the 0x7F frame and another one for single Operations, Not sure to implement quickly , but I like the Idea :-).

Regarding the Flash Erase/programming speed. It is not a question of Size, But is a question of Flash Pages/Sectors size and Technology used. You can see our datasheets. ( It is complex to answer in simple way, but this is among our Technology positioning versus competition)

You can see that STM32F1, F0, F3 and new ones Like STM32L4 have small pages of 1K to 2Kbytes. L0/L1 even smaller pages of hundreds of bytes, but our High performance Products F2/F4/F7/H7 has bigger flash sectors : 8K, 16K, 32K, 64K , then 128K. Erase time depends on our capability to flip all bits of the flash pages/sector to 0x1. However, the most important for 90% of applications is the read/access time, as not so many they will upgrade on the fly, but Once at programming in factory and will take time.

Default Programming is done with 8-bits. But we can accelerate it by a special writing to an Area to 16-bits/32-bits or even 64-bits depending on your VDD. See AN26 You can do it with the command line version - we gave all sources code in the install directory.

Cheers,

STOne-

[STOne-32]

Posted on July 26, 2017 at 21:06

Hi Jason,

We have noticed that you are in direct contact with our Local FAE team @Daniel , so they directly support you on the Technology aspects ;-). 

Cheers,

STOne-32.