Neeraj Dantu
Forum Replies Created
- AuthorPosts
- May 2, 2023 at 12:24 pm in reply to: Error: Illegal access to … when flashing custom board emmc #13527
Damian,
Apologies for the late reply. Currently Octavo’s plan is to support major revisions of OpenSTLinux. Here is the latest meta-octavo layer that supports OpenSTLinux v4.0: https://github.com/octavosystems/meta-octavo-osd32mp1/tree/kirkstone. The device tree files are added in as patches(for example: https://github.com/octavosystems/meta-octavo-osd32mp1/tree/dunfell/recipes-kernel/linux/files for the kernel).
Best,
Neeraj
May 2, 2023 at 11:35 am in reply to: “Getting started with OSD32MP1-BRK ST-Link/JTAG interface” #13526Rob,
Thank you for your thoughts and inputs.
I did notice that we have the 0.05″ TC2050-IDC-NL-050 linked in the “Getting started” post earlier. This should have been the TC2050 with 0.1″ pitch instead and was corrected. The MB1440 add on board for STLink V3 set converts all the 0.05″ connectors to 0.1″ pitch connectors.
The TC2050-ARM2010(https://www.tag-connect.com/product/tc2050-arm2010-arm-20-pin-to-tc2050-adapter) + TC2050-IDC-NL(https://www.tag-connect.com/product/tc2050-idc-nl-10-pin-no-legs-cable-with-ribbon-connector) connect to the 20 pin connector of MB1440, which is plugged in top of MB1441.
Hope that clears things up. Tag-connect is easy to work with, but with the right set of cables. Will pass on your inputs.
Best,
Neeraj
March 27, 2023 at 9:50 am in reply to: Getting started with OSD32MP1-BRK ST-Link/JTAG interface #13494Rob,
Yes, TC2050-IDC-050-STDC14 should work. I verified the setup using items 2a + 2b + ST-Link V3 debugger from the original post.
Best,
Neeraj
Hey Sylvain,
Thank you for reporting this issue. It does appear that VDD stays on after issuing “poweroff” or “shutdown” command. This is likely from a bug in the secure monitor firmware that controls the PMIC. This behavior is consistent in OpenSTLinux V3, on ST dev boards(tested on DK2) as well.
ST’s is switching support to OPTEE for V4 and future releases. I verified that the DK2 does not fail to turn OFF VDD when OPTEE boot chain(https://wiki.st.com/stm32mpu/wiki/Boot_chain_overview) is used. We will update our support for OPTEE for OSD dev boards. We recommend you update your boot chain as well.
Best,
Neeraj
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
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
Issue resolved offline. Root cause is said to be power sequencing.
Best,
Neeraj
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
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
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
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
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
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
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
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
- AuthorPosts
