[Neeraj Dantu]

Hey Julius,

Using the device tree is the recommended way to control power rails of the PMIC. See example here for EV1 board: https://github.com/STMicroelectronics/linux/blob/v5.15-stm32mp/arch/arm/boot/dts/stm32mp15xx-edx.dtsi#L175.

Please also take a look at the EV1 implementation of ADC and DAC here: https://github.com/STMicroelectronics/linux/blob/v5.15-stm32mp/arch/arm/boot/dts/stm32mp15xx-edx.dtsi#L108 and https://github.com/STMicroelectronics/linux/blob/v5.15-stm32mp/arch/arm/boot/dts/stm32mp15xx-edx.dtsi#L146

Best,

Neeraj

[Neeraj Dantu]

Hey Adam,

The junction temperature for AM335x SoC is 105C. However, you do not need to care about it as long as you can ensure your C-SiP device case temperature is within 85C. We only specify case temperature as there are multiple devices inside the SiP and each junction temperature is different.

Best,

Neeraj

[Neeraj Dantu]

Gil,

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.

Best,

Neeraj

[Neeraj Dantu]

Peter,

Pins that can have buttons on them such as PMIC_NRESET and PMIC_PB_IN can utilize a small capacitor for de-bouncing, but the other signals you list are very low frequency and often only change levels once after reboot.

For convenience, the pins that need to be connected are brought out to SiP pins that are adjacent. This minimizes the cross talk. So, caps on these pins are not required. Please note that poor stack-up and routing can always cause issues with the board that can effect these signals, but as long as reasonable layout practices are followed, there is no need to be worried about these signals.

Best,

Neeraj

[Neeraj Dantu]

Gil,

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)?

Best,

Neeraj

[Neeraj Dantu]

Seth,

You can find a lot of help in the application notes for OSD335x listed here: https://octavosystems.com/app_notes/#OSD335x. Specifically, take a look at the tutorial series: https://octavosystems.com/app_notes/osd335x-design-tutorial/.

Unfortunately, fly-wiring an OSD335x-BAS part is more difficult than the C-SiP. So, we do not have a wiring diagram for it, but you can take a look at the design in the tutorial series as something similar. You can use a micro-SD card for boot, but make sure you set the boot mode correctly on the SYSBOOT pins.

Best,

Neeraj

[Neeraj Dantu]

Hey Gil,

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.

Best,

Neeraj

[Neeraj Dantu]

Gil,

I don’t think you can leave CC pins unconnected. Please review https://www.ti.com/lit/wp/slly017/slly017.pdf

As far as I can tell, the option for USB-C you specified does not seem to do anything except for enabling the USB ports. You can directly compare your board device tree USB setup with the BRK here: https://github.com/octavosystems/OSD32MP1-BRK-device-tree/blob/master/tf-a-v2.4-r0/stm32mp157c-osd32mp1-brk.dts#L481. Note that the BRK uses a Micro-USB port.

 

Best,

Neeraj

[Neeraj Dantu]

Gil,

1. 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.

2. Note that you can change pinmux settings in TF-A here: https://github.com/octavosystems/OSD32MP1-RED-Device-tree/blob/main/tf-a-v2.4-r0/stm32mp157c-osd32mp1-red.dts#L547

3. 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.

Best,

Neeraj

 

[Neeraj Dantu]

Banjamin,

In order to get an SSH connection over to the peripheral BRK, you will need to know the IP address of that BRK. You can bring up a console on the peripheral BRK by connecting to UART4 via a USB-UART cable, and then look at the output of ifconfig there. If you do not have an IP address, you can assign a static IP on that board and then you will need to use that IP address to SSH into that board from the host BRk board.

Best,

Neeraj

[Neeraj Dantu]

Gil,

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).

#include “stm32mp15-fw-config.dtsi” should already be part of the OpenSTLinux package you are using. This file is in ST’s sources: https://github.com/STMicroelectronics/arm-trusted-firmware/blob/v2.6-stm32mp/fdts/stm32mp15-fw-config.dtsi

You mentioned that you cannot access the logs from the board because the UART4 interface is not accessible. You can change the console output in TF-A here: https://github.com/STMicroelectronics/arm-trusted-firmware/blob/v2.6-stm32mp/fdts/stm32mp157c-dk2.dts#L28. Once you redirect the console output to a serial interface you can access, you can determine the error in boot more specifically.

Best,

Neeraj

[Neeraj Dantu]

Gil,

You should be able to do TF-A debug with CubeIDE, but there is currently no tutorial to show how it is done. However, you can use gdb as shown here: https://wiki.st.com/stm32mpu/wiki/How_to_debug_TF-A_BL2

Best,

Neeraj

EDIT: Found this: https://wiki.st.com/stm32mpu/wiki/How_to_manage_OpenSTLinux_projects_in_STM32CubeIDE. You can use CubeIDE to load OpenSTLinux projects.

• This reply was modified 2 years, 2 months ago by Neeraj Dantu.

[Neeraj Dantu]

Gil,

Please take a look at https://www.st.com/resource/en/application_note/an5275-usb-dfuusart-protocols-used-in-stm32mp1-series-bootloaders-stmicroelectronics.pdf for detailed information on the DFU protocol. The TF-A being sent over needs to initiate a DFU download of the next stage bootloader(u-boot), which is what is likely failing to do on your board. Please review your TF-A device tree: https://wiki.st.com/stm32mpu/wiki/USBPHYC_device_tree_configuration.

Best,

Neeraj

[Neeraj Dantu]

Peter,

The part for the eMMC used in C-SiP is subject to change. It does adhere to JEDEC standard v4.3 or later(supported by AM335x). JEDEC defines the standard for the eMMC(https://www.jedec.org/standards-documents/technology-focus-areas/flash-memory-ssds-ufs-emmc/e-mmc). The standard allows to use different part numbers as long as they adhere to the JEDEC standards we adhere to. An example datasheet for an eMMC part that can be in the C-SiP can be found here: https://datasheet.lcsc.com/szlcsc/2006081033_Kingston-Technology-EMMC04G-M627-A01_C577446.pdf

Best,

Neeraj

[Neeraj Dantu]

bm,

The kernel boot options can be set in an extlinux file in /boot folder of the SD card. Please see https://github.com/octavosystems/osd32mp1-build-tools/blob/master/stm32mp157c-osd32mp1-red-extlinux.sh#L26 for example. From the boot log, it looks like the kernel is looking for a partition that has a UUID of e91c4e10-16e6-4c0e-bd0e-77becf4a3582. This does not exist on your SD card. The kernel is getting this from /boot/extlinux/extlinux.conf. This is where you can change the root= from the UUID to the root partition ID of your SD card or the UUID of your root partition. You can find the UUID of the partitions of the SD card you are using by inserting it into a Linux computer and running “blkid”. The output of the command is the UUIDs of all devices and filesystem UUIDs.

Best,

Neeraj

[Author]

Posts