Hello,
We were able to resolve this yesterday.
Appeared to be instability on VIN, along with sequencing involving PONKEY. The PMIC TURN_OFF_SR was reporting issues with VIN_OK failure.
@Neeraj,
Is there a roadmap/timeline of when CubeMX app note will be updated and support for v4.0 exists?
Do you plan to update said app-note with other variants?
The app-note STM32MP1 CubeMX Tutorial for OSD32MP15x – Octavo Systems, specifically step 3 in the pre-reqs suggest there are minimal_config projects for different part numbers, the file server only has 1 part # – OSD32MP157C-512M-BAA_MinimalConfig.
I am looking for a minimal_config for OSD32MP157F-512M-BAA_MinimalConfig.
Alright, was able to figure this out.
Needed to include “stm32mp15xf.dtsi” in tf-a, u-boot, and linux device trees.
Seems to go away if I use the STM32CubeProgrammer on Linux (Ubuntu).
I am currently getting this issue on a RED board when programming the eMMC with an image build from the latest meta-octavo.
Neeraj –
Are you still projecting a release in 9/2021?
Just wondering as there is only a week left to 9/2021 and we have been waiting quite some time for said updates so that the OSD boards are inline with STMicro releases.
Thanks Erik,
To confirm, this cannot be tested with a BRK or RED board? The below items do not appear accessible for modification.
BYPASS_REG1V8(M10) needs to be connected to VDD.
VDDA1V8_REG (R7) needs to be connected to VDD instead of being a test point.
Hello,
Can someone from Octavo provide any insight on whether or not this was ever tested -> 1.8V I/O?
“Note that we have not tested this configuration. But, according to the documentation, this is all the changes you need to make for 1.8V operation. We will report back once we verify.”
Essentially, does the latest comment on this thread imply it was verified and works accordingly?
Thank you!
Any updates on this?
Are there plans to move the BRK to OpenSTLinux 3.0?
Thank you for the insight.
We need 2 USB host ports. We are actually already using the port off of PB29/30 with the sparkfun breakout exactly as you mentioned and it works great.
Looking at section 10.1.12, is the OTG block the micro-USB on the BRK? I think it is.
It looks like second port from the usb is not brought out on the BRK.
Is there anyway to use the OTG port as a host?
In the document, “Note: On OTG IP, USB full-speed device is also supported by using Micro-B receptacle instead of Micro-AB and leaving the OTG_ID pin unconnected.” We did precisely this and had the ID pin floating, but saw no change.
Is there a projected timeline of when the migration to the SDK v2.x will occur?
“https://github.com/octavosystems/osd32mp1-debian#flash-emmc”
See above link that is a part of the Debian SDK recently released.
Hi Rishi,
How are you generating the device tree blobs? Your error with dunfell 20-11-12 appears to be on dts parsing.
Did you try following https://octavosystems.com/app_notes/stm32mp1-cubemx-tutorial-for-osd32mp15x? Then copy that stuff into mx folder under meta-st-stm32mp-addons layer in the distribution package?
We have seen some odd things with the minimal config project used in CubeMX to generate device tree blobs.
We essentially used the following link for the BRK board.
https://wiki.st.com/stm32mpu/wiki/How_to_create_your_own_machine
We used the Minimal Config to generate the device trees within CubeMX.
We then copied the mx\project\ into our Distribution package and build.
Lastly, we used the script to generate the SD card image from the .tsv and flashed it to the board, but the board hangs on boot with PANIC at PC : 0x2ffda41b Exception mode=0x00000016 at: 0x2ffda41b.
Is what we are trying possible? Do the patches in the octavo github matter? It appeared some of it was for patching the Developer package to build correctly.
Octavo Systems LLC all rights reserved
OCTAVO is registered in the U.S. Patent and Trademark Office. OSD, C-SiP, and the Octavo Logo are trademarks of Octavo Systems LLC.
"*" indicates required fields
"*" indicates required fields
"*" indicates required fields
"*" indicates required fields