[Neeraj Dantu]

Tomas,

Apologies for the delay in reply. We are testing the port right now on the dev boards. Repos should be updated this week. Thank you for your patience.

Best,

Neeraj

[Neeraj Dantu]

alexandre,

I am not sure what process the SIP pictured went through. If the SIP experienced delamination and cracking, then solder could come out from inside the SIP(could be MSL issue) but that may not be the cause of problem. Cause could be BGA desoldering process which could overheat the part for quick remove.

If it is MSL issue, please make sure you are following storage and reflow requirements described in sections 9.2 and 9.3 in the datasheet(https://octavosystems.com/docs/osd32mp15x-datasheet/)

Are you replacing or re-using the SIP? If so, you will need to be very careful not to damage the SIP.

You also need to dry bake board before removal and bake part before replacing on the baord. Board drying specs are different (lower T and longer duration).

Best,

Neeraj

[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

[Author]

Posts