[Neeraj Dantu]

Sreerag,

The power application note for OSD335x provides information on internal power configuration of the SiP: https://octavosystems.com/app_notes/osd335x-power-application-note/. Specifically, Figure 2 shows the power up sequencing of the SiP. You should be able to map the power up sequencing of the faulty boards against the sequence in Figure 2 to see where the PMIC is experiencing problems while powering up.

Also, make sure to test for the PMIC power rails for shorts. If the boards are operated out of spec, it could damage the PMIC power supplies.

Best,

Neeraj

[Neeraj Dantu]

Farid,

 

Few things to check:

1. For the device tree compatible property see https://www.kernel.org/doc/Documentation/devicetree/bindings/net/broadcom-bluetooth.txt for the appropriate naming scheme.

2. I would set pull-up/pull-down for pins in the pinmux section of the device tree

3. Make sure the driver is finding the right firmware file BCM43xx.hcd and that the file is named correctly. Looks like your file name is “BCM4345C0_003.001.025.0172.0344.1MW.hcd”, not sure this is what the driver is looking for..

4. The bootlog for a working board with Bluetooth should look something like this:

[   13.887871] Bluetooth: HCI device and connection manager initialized

[   13.892812] Bluetooth: HCI socket layer initialized

[   13.897656] Bluetooth: L2CAP socket layer initialized

[   13.956382] Bluetooth: SCO socket layer initialized

[   14.024362] Bluetooth: HCI UART driver ver 2.3

[   14.027388] Bluetooth: HCI UART protocol H4 registered

[   14.065541] Bluetooth: HCI UART protocol Broadcom registered

[   14.444703] brcmfmac: brcmf_fw_alloc_request: using brcm/brcmfmac43430-sdio for chip BCM43430/1

[   14.479055] Bluetooth: hci0: BCM: chip id 94

[   14.482570] Bluetooth: hci0: BCM: features 0x2e

[   14.488523] Bluetooth: hci0: BCM43430A1

[   14.490927] Bluetooth: hci0: BCM43430A1 (001.002.009) build 0000

[   14.498956] Bluetooth: hci0: BCM43430A1 ‘brcm/BCM43430A1.hcd’ Patch

[   14.678856] brcmfmac: brcmf_fw_alloc_request: using brcm/brcmfmac43430-sdio for chip BCM43430/1

[   14.768279] brcmfmac: brcmf_c_preinit_dcmds: Firmware: BCM43430/1 wl0: Feb 16 2020 22:39:24 version 7.45.98.97 (r724416 CY) FWID 01-bf41ed64

[   15.240495] Bluetooth: hci0: BCM4343WA1 37.4MHz Murata Type-1DX BT4.2-0093

[   15.245961] Bluetooth: hci0: BCM43430A1 (001.002.009) build 0395

This is from bootlog for OSD32MP1-RED with CY4343W chipset. Comparing this to t=your log, it does seem like there bluetooth firmware file is not being loaded. Folks at Murata should be of more help on the chipset you are using.

Hope this helps.

Best,

Neeraj

 

[Neeraj Dantu]

Answered in another thread. You can use the patches in meta-octavo-osd32mp1 layer.

Best,

Neeraj

[Neeraj Dantu]

Pratik,

You are correct. You can use the patches for meta-octavo-osd32mp1 layer.

Best,

Neeraj

[Neeraj Dantu]

Pratik,

Thanks for the logs. This is interesting. From the logs it looks like the driver was unable to shutdown the peripheral successfully: https://github.com/torvalds/linux/blob/v5.4/drivers/tty/serial/stm32-usart.c#L644. Given that you are not seeing this on kernel 5.10, the bug must be fixed in the updates to the driver. Upgrading the kernel seems to be the easiest way to resolve this issue.

Best,

Neeraj

[Neeraj Dantu]

Thanks Aedan!

Pratik,

As it is clear that the behavior you are seeing cannot be reproduced independently, I would suggest looking at your board configuration. In addition to Aedan’s inputs, here are a few things to check:

1. Probe signals and see if you can actually see the traffic you are generating on each interface and narrow down where during the transmission you are running into issues.

2. Check the pinmux configuration(https://github.com/octavosystems/OSD32MP1-BRK-device-tree/blob/master/linux-v5.4/stm32mp157c-osd32mp1-brk.dts#L268) and peripheral configuration(https://github.com/octavosystems/OSD32MP1-BRK-device-tree/blob/master/linux-v5.4/stm32mp157c-osd32mp1-brk.dts#L1063) in the device tree as compared to the BRK on your custom board.

Best,

Neeraj

[Neeraj Dantu]

Noel,

Apologies for the late reply. It seems that your post was stuck in our SPAM filter.

Looking at the power up sequencing of the good part vs bad part you attached, it looks like several of the output rails do not come up. Specifically, LDO2, LDO3, DCDC2 and DCDC3 do not come up, indicating a short on 1 or more of these power rails. Can you check for shorts on these power rails?

Shorts like this could be caused if the recommended handling procedures are not followed. If you have more parts, we recommend you bake at 125C for 35 to 48 hours before you try to put them on the boards and reflow. The recommended handling procedure is described in sections 9.2 and 9.3 of the datasheet: https://octavosystems.com/docs/osd335x-sm-datasheet/

If you have X-ray capability, you can image the failed parts to see any solder flow inside the SiP.

Best,

Neeraj

[Neeraj Dantu]

Carlos,

The log indicates that there is no USB interface found on the board. Can you check if you defined the USB interface in u-boot device tree?

The patch you linked creates a new machine and a separate board.c initialization file for BRK. So, it may not work without further modification. The board.c in the patch is modified from the default ST board.c file to avoid use of STUSB1600 USB-C Controller chip as BRK implements a Micro-USB OTG port instead of a USB-C.

Best,

Neeraj

[Neeraj Dantu]

Tomas,

The current schedule has OpenSTLinux v4.0 support for end of Oct.

 

If you have any specific question or difficulty in the mean time, please feel free to generate a forum post. Thank you for your patience.

Best,

Neeraj

[Neeraj Dantu]

m10,

This has fallen off the priority list previously. The apps team will complete work on support for OpenSTLinux v4.0 in Oct. I will try to add this to the release package. Will update here when I have an update.

Best,

Neeraj

[Neeraj Dantu]

Tomas,

The team is working on the update now. Will have an expected release date by 9/19.

Best,

Neeraj

[Neeraj Dantu]

mwlinux,

Did you bake the replacement part before putting the board through reflow?

Best,

Neeraj

[Neeraj Dantu]

gil_he,

We recommend checking the PCB shop you work with on their rework capabilities. You can take a look at https://www.ti.com/lit/an/slva439a/slva439a.pdf.

The soldering profile is does not change for replacing the part. However, note that you will need to bake the replacement part before you put the board through reflow to avoid any MSL related failures.

Best,

Neeraj

[Neeraj Dantu]

EmmaKa,

 

Please take a look at your circuit for SD card Detect pin. Card detect pin was not polled in v1.2 image. In v3 image, card detect pin is defined here: https://github.com/octavosystems/meta-octavo-osd32mp1/blob/dunfell/recipes-bsp/u-boot/files/0008-Add-OSD32MP1-RED-Device-tree-support.patch#L1526. GPIOE 7 must be pulled LOW or you can disable card detection in u-boot device tree.

See README for https://github.com/octavosystems/meta-octavo-osd32mp1.

Best,

Neeraj

[Neeraj Dantu]

Gil,

1. Please make sure the GNDs for both board are connected.

2. Probe the SCL and SDA pins to see if they are pulled up to 3.3V.

3. Probe the SCL and SDA activity when you exercise the i2cdetect command. Can you see activity?

4. Please make sure the right I2C device is being used. The Linux I2C numbering can be different from the hardware I2C numbering.

best,

Neeraj

[Author]

Posts