[gil_he]

Dear Eshtaartha,

Thank you for your reply.

We followed the guidelines.

The meta-layer Kirkstone support has Linux version 5.15.24.

It DOES NOT support SPI slave configurations.

Only from Linux version 5.15.67 SPI slave is supported.

Can we build the 5.15.67 Linux version and use the patches in your 5.15.24 version support?

thanks

Gil

 

[gil_he]

Hi Neeraj,

The gibberish was shown using two different usb-serial adapters.

I know these adapters connect successfully to a 3.3V serial bus.

The only explanation I can find is that the stlink is specifically required to interpret correctly the SoC uart data.

I assume this can be verified with ST.

thanks

Gil

[gil_he]

Hi Neeraj,

Behavior is the same in BRK, RED and in our board.

The UART in the SiP sends the correct baud rate. In addition, electrically, the signals are correct.

It seems the debugger is sending the ascii symbols properly, and the terminal shows them correctly.

When connecting the SiP directly to a serial to usb and to a pc, I see gibberish.

The only explanation I have is, something in the debugger (fw or hw) translates the SiP uart correctly to the terminal.

Gil

[gil_he]

hi Neeraj,

An update:

I was able to receive readable uart4 output (not gibberish) ONLY when using the STLINK (as a uart to usb interface).

Direct connection of the SiP uart interface (via generic serial to usb), using numerous terminals, showed only gibberish.

thanks

Gil

 

 

[gil_he]

Hi Neeraj,
1. 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?

2. I tried many different setups using Putty. Always giberish.
I will further debug the uart4.

thanks

Gil

• This reply was modified 1 year, 10 months ago by gil_he.

Attachments:

1. 

   usb_lucid40.png
   

[gil_he]

hello Neeraj,

(1)

Regarding the USB configuration:

We have the USB port in the SiP connected to a USB Type C connector.

VBUS in the connector is connected to the SiP.

Our device will act as a peripheral (device) and DRD. PA10 is not connected.

The only pins connected to the type C are USBDP2/DM2 and OTG_VBUS.

See enclosed picture from CubeMx: We defined OTG/Dual_Role_Device Type C and checked “Activate_VBUS”.

Is the following setup correct?

(2)

We don’t have any other UART pins, in the SiP, that can be routed to the debug connector.

The only pins are for UART4 but not the default ones, so, until we change it (in UBOOT), we cannot use it.

(3)

We connected the UART4 connector in the Octavo BRK and RED, and see giberish on the terminal.

Trying all available settings (translations, com settings) did not help.

Why can’t we see clearly the logs on uart4?

thanks

Gil

• This reply was modified 1 year, 10 months ago by gil_he.

Attachments:

1. 

   CubeMx_USB_OTG.png
   

[gil_he]

hello Neeraj,

I’ve taken a correct CubeProgrammer sequence (from https://community.st.com/s/question/0D53W000007Y3WmSAK/using-stm32cubeprogrammer-v220-to-program-sd-card-of-our-board-the-board-is-base-on-stm32mp157cdk2-but-fail-and-get-error-messageerror-start-operation-failed-at-partition-0x01error-tsv-flashing-service-failed)
and compared to AN5275, figure 3, page 6.

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

thanks

Gil

• This reply was modified 1 year, 10 months ago by gil_he.
• This reply was modified 1 year, 10 months ago by gil_he.

[gil_he]

hello Neeraj,

I was able to connect the RED to the debugger using SWD.

I need to perform some wire stitching before I can connect our board to the debugger using SWD.

My question:

Can we use the CubeIDE to debug the FSBL load/run process via SWD connection?

Can you guide me on what should be done?

thanks

Gil

• This reply was modified 1 year, 10 months ago by gil_he.

[gil_he]

hello Neeraj,

I have gone through the article you sent.

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

thanks

Gil

• This reply was modified 1 year, 10 months ago by gil_he.
• This reply was modified 1 year, 10 months ago by gil_he.
• This reply was modified 1 year, 10 months ago by gil_he.

Attachments:

1. 

   STMCubeProgrammer_1.png
   

2. 

   STMCubeProgrammer_2.png
   

3. 

   STMCubeProgrammer_1-1.png
   

4. 

   STMCubeProgrammer_2-1.png
   

[gil_he]

hello Neeraj,
I verified your comments.

All is, as required.

I am using STM32cubeProgrammer as stand-alone (not part of CubeIDE).

Installed the latest software. I hope it installs the latest drivers.

Still, no response from the debugger.

 

We don’t have a ST EV1.

Can you verify the RED and STLINK-V3 communicate in your lab?

In our lab they don’t.

 

I compared the signals the debugger send to the RED and to our project. They are very much alike.

J_TDO has no activity.

 

thanks

Gil

• This reply was modified 1 year, 10 months ago by gil_he.

[gil_he]

An update:
I connected the debugger (STLINK-V3SET) to the Octavo RED.

Also added the NRST and NJRST signals from the RED to the Debugger (pins 12 and 11 respectively).

Still, no response.

The CubeProgrammer doesn’t recognize the Octavo SiP.

• This reply was modified 1 year, 10 months ago by gil_he.

[gil_he]

hello Michal,

Thank you for a detailed reply.

We still don’t have Linux and UBOOT.

We want to know if there is a way to program the FSBL only to the eMMC given we don’t have the SSBL and Linux.

Our board is in bring-up stage.

thanks

Gil

[gil_he]

hello Neeraj,

Are the solder bumps (solder balls) on the OSD32 Pb Free?

Should we use a Pb Free or SnPb reflow profile?

I understand the Peak temperature is package dependent.

Can you send a recommended reflow profile for the OSD32?

thanks

Gil

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

[gil_he]

Hi Michal,

Do you recommend using the reflow profile you sent for soldering a new OSD32?

thanks

Gil

[gil_he]

Hi mwlinux,,

We sent the board for a selective reflow replacement of some other device, and the board came back with the OSD32  defective.

The PMIC_BUCK4 gives a wrong voltage (very low).

I wonder if the replacement process somehow damaged the OSD32.

So, we want to remove the defective OSD32 and place a new OSD32 instead.

I understand the difficulties you mentioned are with regard to assembly of a used device, not a new one. Is that correct?

So, we don’t need any reballing.

Take the stencil we have, take a new OSD32 out of the bag, bake it (or not) and assemble according to the reflow you posted.

Am I correct here?

Do we also risk the 5V to GND shortcuts?

Thank you,

Gil

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

[Author]

Posts