The issue in the link starts with partition 0x01 (FSBL), which is exactly what we see, but then changes to partition 0x03 (SSBL), which is not relevant for us.
How can we debug that? (we don’t have JTAG working).
Can that be related to the Clock Configuration in the STM32CubeMX? Will it help to send you a screen shot of the configuration?
Can you post the output on your Cube Programmer command line as well as the output on the console for the board? The output on the console of the board should reveal the error that has occurred during the download.
Please also update the Cube Programmer on your machine as we have seen issues when using an incompatible version between Cube Programmer and OpenSTLinux.
It talks about the UBOOT (partition 3) which disconnects/re-initializes the USB and that may cause a reconnect to fail.
Does the FSBL (partition 1) also acts like that?
In my design, OTG_VBUS is connected to the VBUS pins of the USB3 type C connector we have in the board (we use it as USB2), so it gets the 5v from there.
The OpenSTLinux version we use is “dunfell”. I installed the latest V2.12.0 CubeProgrammer.
Find enclosed the output of the CubeProgrammer during download (first pic is after connection. 2nd is after downloading).
We don’t have working UART port so cannot send the output on the console for the board (we will have UART only after UBOOT loads and we change pin muxing).
I think, we passed the “Authenticate and start TF-A (in SYSRAM)”, so it seems our USBC port is configured as required (TF-A load is successful).
So, we are in either “Get boot config from BootRom” or “init clock and DDR” states.
Do you agree?
(I do not think we reached the “FlashLayout & start” state).
What can cause our start operation to fail?
Is it the files used to create the tf-a.stm32 binary?
Maybe the clock configuration tree?
Also:
The GenerateCode of the CubeMx gave us three files (under the TF-A folder):
stm32mp157c-lucid40_p1-mx-fw-config.dts
stm32mp157c-lucid40_p1-mx.dts
stm32mp15-mx.dtsi
The file, stm32mp157c-lucid40_p1-mx-fw-config.dts, has an include to a dtsi file which we don’t have.
It has only these two lines: #define DDR_SIZE 0x20000000 /* 512MB */ #include “stm32mp15-fw-config.dtsi”
Should we rename the include to “stm32mp15-mx.dtsi”?
It does seem that the board is able to boot via USB with the TF-A loaded. However, note that the USB configuration is from the internal ROM code. The TF-A also needs to be able to exercise the USB port correctly in order to load the next stage(U-Boot).
The hardware connections sound ok. One thing to check is the CC pin configuration. Are you using a USB-C controller chip like STUSB1600 to manage dual role function?
The CubeMX setup looks okay as well. I would check the device tree generated against a DK2/RED/BRK. Since the board connects to Cube Programmer initially, this feels like there is a configuration issue at TF-A. If you are using the same USB port and non-volatile memory interface(eMMC) as OSD32MP1-RED, you can use the same setup with a RED board to eliminate issues with the custom board as the cause for this issue.
I am not quite sure what the setup is with the RED/BRK and which board firmware version you are using. I would start with https://github.com/octavosystems/meta-octavo-osd32mp1 since it is a known verified OpenST image. The UART settings should be 115200, 8N1. Gibberish on the terminal might also mean the host computer is not properly interpreting the data on the terminal. It might need a different terminal window or a reboot. See if you still see gibberish if you are entering data on that terminal via keyboard.
We don’t use a chip like the STUSB1600. The SiP USB port is connected directly to the type c connector (as I described above).
The type C is just a connector. We work with it as if it’s USB2.
The CC pins are NC in the type C connector.
See attached picture. We also don’t use the OTG_HS_ID.
Setting on the CubeMX is OTG/Dual_Role_Device Type C and checked “Activate_VBUS”.
To your understanding, is that ok?
I tried many different setups using Putty. Always giberish.
I will further debug the uart4.
It sounds like the application on your host machine works correctly. You can also do a quick check on the USB-UART cable and verify it independently. The next step then is to see if all your boards are having the same issue. If that is the case, the issue might be related to the firmware you are using. For example, if the UART peripheral is receiving the wrong clock ans not setup properly in the device tree, it is possible to have timing mismatches that could result in the gibberish you are seeing.
If you are still having issues, please feel free to contact us offline with more information on what you are seeing.
The conclusions we can draw from the behavior you are seeing are:
UART output of the SiP is expected
Your host computer is fine given that it can interpret ST Link’s UART signals
Device frequency setting is good as you are able to decode signals from ST Link without issue.
Unless you can verify the UART-USB cable independently, I would assume that the cable is bad. May be take a look at the voltage setting on the cable(5V vs 3.3V)?
Another thing to check is proper GND connection between the board and the UART cable. This method of communication is used all the time by most embedded developers. So, it is unlikely that there is an issue with the use case with 3 different boards.