[Neeraj Dantu]

Hey Rob,

You are correct. 3.0 is the latest image on the web. There are minor bugs in the 4.0 images mainly related to audio for the RED board. I will try to push latest images to the web in the next couple of weeks. There is a detailed image generation procedure you can follow in the README: https://github.com/octavosystems/meta-octavo-osd32mp1/tree/kirkstone which should generate images you can use. Please let us know if you face any issues here.

I was able to use CubeIDE to debug code on the M4 in Production mode(Linux) with the 3.0 image. Can you let us know what issue you are facing?

You might have incorrect debug configuration in the project you are trying to run. Here are a few inputs on the setup:

1. Please see https://octavosystems.com/forums/topic/getting-started-with-osd32mp1-brk-st-link-jtag-interface/ for setup required for STLink connection with Cube IDE

2. The debug settings should be:

– “thru Linux core”, Serial Port: [STLINK serial port], Inet address: 192.168.7.1, Debug Probe: ST-LINK, Connection setup: SWD, 8MHz

Best,

Neeraj

[Neeraj Dantu]

Rob,

OSD32MP1-RED V1.2 board has a different Ethernet PHY than V1.1. You will need to use the upgraded v1.2 image available in the software section of the board webpage: https://octavosystems.com/octavo_products/osd32mp1-red/#Software.

Please see https://github.com/octavosystems/meta-octavo-osd32mp1 and https://github.com/octavosystems/osd32mp1-debian for the source code and methods to build images.

Best,

Neeraj

[Neeraj Dantu]

Issue resolved offline. Root cause is said to be power sequencing.

Best,

Neeraj

[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 1 year, 9 months ago by Neeraj Dantu.

[Author]

Posts