STM32CubeProgrammer fails with: "Error: Message from Embedded Flash Loader : Layout line 1: invalid option '¸' in ¸)"

[Moises Araya]

Hi community,

I'm facing problems to upload the flash layout on a custom board with the STM32CubeProgrammer. I tried with the last version (v2.10.0) but also older ones. The USB communication seems to be working fine as there are not checksum errors or alike. However, for some reason UBoot can still not parse the uploaded layout.

Any idea how this problem can happen even if the USB communication is correct? Could this be a RAM misconfiguration problem even if UBoot can run from RAM and the basic UBoot RAM tests are successful?

For more information, I attach the STM32CubeProgrammer log and the UART4 log.

Thank you in advance for any insight!

Bests,

Moises

[PatrickF]

Hi @Moises Araya​ ,

probably unwanted characters or missing 'tab' in your TSV file.

Please check https://wiki.st.com/stm32mpu/wiki/STM32CubeProgrammer_flashlayout#FlashLayout_file_format

Regards

[Moises Araya]

Hi @PatrickF​ ,

thanks for helping! I read the article you mentioned and did some more tests to figure out what is going on with the TSV file. There are some insights pointing out that the TSV file is actually fine:

• I directly use the TSV file from Yocto and even removed the header to avoid unwanted characters but it still doesn't work. My TSV is attached for verification.
• If I copy the same TSV and use it with other board (different RAM), it works fine. What I do to keep the very same TSV is just to change the name of the binaries so that I don't need to touch the TSV itself but just change the binaries' names. This works just fine, which means the TSV structure and characters is fine.

Is there a way I can debug this from UBoot or TF-A? Could it be that TF-A and UBoot don't agree on the RAM address of the transferred TSV because a wrong device tree configuration?

Thanks in advance!

Bests,

Moises

[PatrickF]

Hi,

seems there is some inconsistencies in your setup:

• seems you have an STM32MP151D (single core 800MHz CPU), but u-Boot log mention that it was compiled targeting an STM32MP157A (which is a dual-core 650MHz CPU)
• your TSV uses tf-a-serialboot.stm32 and ssbl, which make me think your are using an Ecosystem v2.x whereas the UART log show U-Boot 2020.10 which is for Ecosystem v3.x

Please try to solve all those issues

If possible switch to Ecosystem v3.1 and use FIP.

Regards.

[Moises Araya]

Hi @PatrickF​ ,

Thanks for your answer. Here some more info from my side on your comments:

• You are right, the UBoot log mentions a STM32MP157A and we are actully using a STM32MP151D with TFBGA257 package, however the device tree was modified to work with the right processor. Just forgot to update the "model" and "compatible fields" of the device tree, this is now corrected. Let me know if I should attach some relevant device configuration from the DT.
• We are using the latest OpenSTLinux distribution, however at the moment we just need a simple boot scheme. That's why I set MACHINE_FEATURES_remove = "fip" just as set in the meta-st-stm32mp/conf/machine/stm32mp1-eval.conf. As far as I understand the new Ecosystem (v3.x) and UBoot 2020.10 sould work without FIP, shouldn't it?

The weird part is that I have another prototype running with the same processor but the TFBGA361 package. Both Yocto machine configurations use the same UBoot/TF-A/Kernel defconfigs and boot scheme. What changes is basically the pining and RAM (16-bit LPDDR2 on the TFBGA257 and 32-bit LPDDR2 on the TFBGA361) which is done in the DTs.

I attach the new boot logs as they change intermittently. Some times the Layout error doesn't get propagated to the CubeProgrammer which instead shows "Error: an error occured while uploading data from the virtual partition 0xF1".

Bests,

Moises

[PatrickF]

Hi,

As this has changed from your other project, maybe double check your DDR settings and PCB connections, there might be some issue in size definition (which might create physical memory overlaps or else, very hard to debug due to cache).

Check also your timing settings are correct (Using u-Boot SPL and CubeMx DDR Tools).

Regards.

[Moises Araya]

Hi @PatrickF​ ,

I do have some unexpected behaviour with the DDR Tuning tool as follows:

• The DDR Test Suit can connect to the board and all tests are successful.
• The DDR Tuning finds some parameters which are mostly consistent over multiple runs of the Tuning tool.
• However, if I load the tuning parameters to the RAM, it just stops working and I get the error "Loading execution abnormally long, you must check and re-initialize the connection"
• It doesn't work neither if recompile the BSP skiping RAM built-in calibration and use the tuning params.

I'm using the Winbond W97AH6NB / W97AH2NB RAM. The CubeMx RAM configuration looks like this:

 

My current questions:

• How is it possible that I can boot up to Linux, run the UBoot and CubeMx RAM tests succesfully but using the tuning params doesn't work?
• Do you see any possible missconfiguration that can cause this?

Regarding the relation with the DUF problem: it can be that the RAM is still not fully functional when the TF-A starts writing the layout on it with the programmer, and for this reason it gets corrupted.

Bests,

Moises

[PatrickF]

Hi,

I suspect also an issue with the LPDDR2. Not expert enough to comment your values.

Please confirm you have a 100 ohms resistor between DDR_CLKP and CLKN (close to LPDDR pins). We recently discover that this info is missing in AN5031, but present in AN5122 and routing examples.

Btw, please double check the tf-a-serialboot.stm32 you are using is really using the same parameters you have in tf-a-trusted.stm32 (as you mention that you boot up Linux, so likely using this latest one).

As it seems you are using 800MHz without STPMIC1, please confirm your VDDCORE is set at 1.35V before going above 650MHz.

I see you are using Ecosystem V3.0, I encourage you to move to latest Ecosystem v3.1 which has (beside other updates) one specific update for LPDDR (not sure it is linked to your issues)

• Enabling LPDDR2 / LPDDR3 PHY built-in read valid training (RVTRN)

Regards.

[Moises Araya]

Hi @PatrickF​ ,

We have tried a couple of things you suggested and I would like to update about the partial results:

• I'm using TF-A out-of-the-box (no own recipe nor own defconfig). And in the machine config I set both CUBEMX_DTB_PATH_TFA and CUBEMX_DTB_PATH_TFA_SB to the same directory. So there shouldn't be any device tree or configuration difference between those two.
• You are right, we have passive power supply but checked VDDCORE and it is at 1,37V without significant variations in the mV range (300MHz oscilloscope). DDR_VREF is also withing the accepted peak-to-peak noise of the Winbond RAM.
• I updated our BSP to the Ecosystem V3.1 and got same results. I attach the logs again for comparison.
• We do not have a 100Ohm resistor between DDR_CLKP and DDR_CLKN but unfortunately it would mean to layout and order again our PCBs to correct this impedance termination on the clock.
• Reviewing some of the application notes we discovered that we don't meet a layout rule from AN5122: "CLK_N/CLK_P must be the longest traces".

Everything points out to RAM layout problems. So If you don't see anything suspicious line in the attached log, I think we need to correct the layout to discard any hardware problem before continuing debugging the software.

Thanks a lot for your support and hints.

Bests,

Moises

[PatrickF]

Hi,

before going to a new PCB, I think it would be worth to check DDR setup and timing with DDR Tools.

Please have a look to https://community.st.com/s/article/FAQ-STM32MP1-Bring-up-procedure and https://community.st.com/s/article/FAQ-STM32MP1-how-to-validate-the-STM32MP1-DRAM-connection-on-PCB-DDR-test-suite

Don't know about your application, but notice that running full time VDDCORE=1.37V have impact on estimated lifetime. See AN5438 for details.

Regards.