Problem with Flash Loader Demonstrator and STM32F407ZG

[Fristedt.Jan]

Posted on June 11, 2013 at 13:02

Hi,

I'm trying to use FLD v2.6.0 with STM32F407ZG rev Z. No problem to connect, uploading an image written by SWD works most of the time, erasing and downloading gives mixed error messages such as for example that erase isn't supported by the device. Disabling protection is hit or miss.Are these known problems? Are these user (me) problems? I have had very few problems with earlier versions of FLD and STM32F103.Any hints?Now I will copy this text to the clipboard before I submit it so I don't have to retype it again. #stm32f407-flash-loader-demo

[frankmeyer9]

Posted on June 11, 2013 at 13:51

Any hints?

Possibly bandwidth issues with the serial cable ? Reducing the baudrate should help in this case. Or increase the timeout value in the serial settings, in case of interference with erase duration. Power supply issues could also interfere with erasing/programming in extreme cases.Now I will copy this text to the clipboard before I submit it so I don't have to retype it again. Welcome to the club. Usually, hitting the browser's ''back'' button on the error page will bring your editings back. Trying to resend it from there will fail almost certainly, though.

[Fristedt.Jan]

Posted on June 11, 2013 at 15:44

Thank you for your suggestions. 

The power supply is a good suggestion. The baudrate not very likely since I only used 38400, but how could you know.However, I tested with a large reservoir capacitor on the connector to the board in addition to the capacitors on board. No luck, same symptoms.Next test was with 9600 baud. Didn't help.

[frankmeyer9]

Posted on June 11, 2013 at 16:23

You only gave the MCU type, but no further hint to the hardware.

I assumed an evaluation board, which do not usually suggest such problems. I only experienced this when attaching a power-hungry LCD display. Otherwise, the additional power requirements for flash erasing/programming are not significant. The baudrate not very likely since I only used 38400, but how could you know. I agree, that should not be the problem under normal circumstances. Keep the cabling short (less than 1m) and with a consistent  RF impedance (i.e. twisted pair, flat ribbon or shielded) will help. How do you interface the UART, i.e. do the level-shifting towards the PC ? Have you observed the RX/TX signals with a scope ? Does access via JTAG/SWD work ?

[Tesla DeLorean]

Posted on June 11, 2013 at 18:43

In terms of problems we've seen issues with a couple USB-to-Serial adapters not performing reliably, the System Loader is a bit of a one-shot deal it's measuring the 0x7F data pattern with 8E1 (Even Parity) rather than reading it into the USART so if the pattern isn't clean nothing else will work well and the STM32F4-Discovery can't use USART1 PA9/PA10 due to a large bulk cap.

I've played with F2/F4 parts using USART3 PB10/11, and DFU via USB, both offered reasonable success. Within my own domain I also provide update via SD Card, X-Modem and  HTTP Get.

[Fristedt.Jan]

Posted on June 12, 2013 at 09:22

The hardware is a custom built board.

I have used USART1 on the board as a ''trace port'' extensively with an FTDI cable up to 460800 baud during development of the firmware without any noticeable problems.The SWD works rather well.Since there is no problem connecting the baud rate detection with 0x7f obviously is not a problem.

[frankmeyer9]

Posted on June 12, 2013 at 10:37

The hardware is a custom built board.

I have used USART1 on the board as a ''trace port'' extensively with an FTDI cable up to 460800 baud during development of the firmware without any noticeable problems. The SWD works rather well. This was the background of my question. There are several thread in this forum, reporting problems most probably caused by less-than-optimal PCB design. This seems not to be the case with your problem. As clive's post suggests, the flash loader demonstrator software seems not to have the robustness required for an automated process, as flash programming in PCB process. I tend to interpret the name ''demonstrator'' in that way. And, to be honest, up to now I used this tool only for mass-erase, to get rid of ''erratic'' applications on the target.

[Fristedt.Jan]

Posted on June 13, 2013 at 10:01

I guess I will have to find the source for an old application I did where one STM32F103 programmed three STM32F103 via USARTs and convert that to something that's possible to run on the PC. Sad...

How do you guys program your processors in production? SWD?

[frankmeyer9]

Posted on June 13, 2013 at 10:50

How do you guys program your processors in production? SWD?

In practical terms, yes. My current company does not use Cortex M controller yet. But in production equipment, standard debug pods are used (for whatever protocol the target requires). Programming software are mostly cmd-line applications provided by the MCU vendor, or self-written software, using some vendor library/DLL. These are called in batchmode, or from some other app like Labview. Having been around in this production test business for some years, I noticed this approach is not so uncommon. You could ask  the silicon vendor (ST) or your toolchain vendor which equipment is recommended for production.

[Fristedt.Jan]

Posted on November 06, 2013 at 11:10

Hi All, I'm back again!

I still have problems with the flash loader demonstrator and have seen similar problems in another project at another company. If we start with the most basic, erasing the whole chip. Attached you can find screendumps of the five steps for erasing the chip.The loader connects but it's not possible to erase. Just to save you all the trouble to ask questions about the board, it's ok. Power is ok. Decoupling is ok. Layout is ok. It works very well with SWD. And yes, we need a way to download a patched hex file in production. TIA ________________ Attachments : fld_erase.zip : https://st--c.eu10.content.force.com/sfc/dist/version/download/?oid=00Db0000000YtG6&ids=0680X000006I141&d=%2Fa%2F0X0000000bhd%2FZhoPHCB69cssXdVHg035oIGrS45FaoiFwCNGhfSWy90&asPdf=false