[Erik Welsh]

This is most likely due to the firmware being loaded as part of the BRCM driver for the WiFi module. By default, channels 12 and 13 are not allowed in North America (https://en.wikipedia.org/wiki/List_of_WLAN_channels#2.4_GHz_(802.11b/g/n/ax)). In the default device tree, we do not specify any country codes for the BRCM driver: https://github.com/octavosystems/OSD32MP1-RED-Device-tree/blob/main/linux-v5.10-r0/stm32mp157c-osd32mp1-red.dts#L1286 Therefore, the driver most likely defaults to loading the firmware for North America since not using channels 12 and 13 is ok everywhere in the world even if they are available. If you look at the device tree bindings for the BRCM driver: https://www.kernel.org/doc/Documentation/devicetree/bindings/net/wireless/brcm%2Cbcm4329-fmac.yaml you can see that there is a “brcm,ccode-map” attribute that can be set. Try setting this parameter appropriately for your country and see if that fixes the problem.

Thanks,
Erik

[Erik Welsh]

If you can guarantee the behavior of the power rails attached to VDDS and VDDSHVx do not violate the AM3358 specification, then you do not need the clamping circuit.  Please see the full write up on the clamping circuit in the application note:

https://octavosystems.com/app_notes/osd335x-design-tutorial/bare-minimum-boot/clamping-circuit/

 

Please let us know if you have any additional questions.

Thanks,

Erik

[Erik Welsh]

We apologize for the trouble you experienced contacting us.  Hopefully everything should be sorted out.  Please let us know if you have any additional questions.

Thanks,

Erik

 

[Erik Welsh]

Our System-in-Package (SiP) devices are rated for case temperature, not junction temperature as case temperature encompasses all of the components that are within a SiP.  You can find information on the thermal characteristics of the OSD3358-SM in our thermal application note:  https://octavosystems.com/app_notes/osd335x-sm-thermal-guide/

Please let us know if you have any additional questions.

 

[Erik Welsh]

Please check that the pin is configured correctly in the GPIO registers.  You can find information on this in the TRM:

https://www.st.com/resource/en/reference_manual/rm0436-stm32mp157-advanced-armbased-32bit-mpus-stmicroelectronics.pdf

The GPIO register definitions are in Section 13.4 (page 1077).  Table 82 (page 1068) shows how the register bits define the pin configuration.  Also, Section 13.3.8 (page 1071) discusses the wakeup pins.  Finally, the base addresses for each of the peripherals can be found in Table 9 (page 159 – 166, gpio peripherals are on page 162).

Let us know if you continue to have problems.

 

 

 

[Erik Welsh]

From a prototyping perspective, you can use the randomly generated address in Debian.  However, for your production product, you will need to consult your legal department on what is required for your product to operate.  We would recommend contacting the IEEE Registration Authority (https://standards.ieee.org/products-services/regauth/index.html) to better understand the requirements.

[Erik Welsh]

Yes, 1.8V I/O operation of the OSD32MP1 was verified and added to the datasheet (https://octavosystems.com/docs/osd32mp15x-datasheet/).  See sections:  6.1.1 on I/O voltages and 7.6.3 on the discussion about the VDD power rail.

You will need to modify the device tree to set the I/O voltage and PMIC outputs appropriately.  Additionally, see Section 10 of:

https://www.st.com/resource/en/application_note/dm00389996-getting-started-with-stm32mp151-stm32mp153-and-stm32mp157-line-hardware-development-stmicroelectronics.pdf

for examples of 1.8V operation of different interfaces.  Please let us know if you have any additional questions.

[Erik Welsh]

You will need to modify the device tree in order to update the hardware configuration.  You can find the BRK device tree in our github repository:

 

https://github.com/octavosystems/OSD32MP1-BRK-device-tree/blob/master/linux-v5.4/stm32mp157c-osd32mp1-brk.dts#L943

 

The code around line 943 (i.e. the line referenced in the link) is the USB configuration that is set on the BRK.  As you can see, the usbotg_hs device tree node is set to the USB1. You will need to modify the device tree and then recompile to update the software image.  You can find information about that process:

https://github.com/octavosystems/BRK_Developer_Package_patches

 

Additionally, depending on when you need the USB functionality, you might need to also modify the u-boot device tree.  See https://github.com/octavosystems/OSD32MP1-BRK-device-tree  for all of the device trees used for the BRK.  If you have questions on device tree, we would recommend reading:  https://octavosystems.com/app_notes/osd335x-design-tutorial/osd335x-lesson-2-minimal-linux-boot/linux-device-tree/  as an introduction to device trees.  Additionally, there are many documentation resources on the STM wiki for the MP1 on  https://wiki.st.com/stm32mpu

 

• This reply was modified 3 years, 2 months ago by Erik Welsh.

[Erik Welsh]

Thanks for clarifying.

Do you have any way to temporarily change your boot order?  If you look at the OSD3358-SM-RED reference design, by pulling SYSBOOT[2] low (i.e. pressing switch S3 which is connected to LCD_DATA[2]), you can change the boot order to “SPI0, MMC0, USB0, UART0”.

If not, then you can connect an eMMC to MMC0 and microSD to MMC1.  However, in this case, you will only use 4 data lines for each interface.  Unfortunately, MMC0 only pins out 4 data lines but you can still use that to communicate with an eMMC module.  It will reduce your throughput but will not affect functionality.  Just leave the upper four data bits (i.e. DAT4 – DAT7) of the eMMC unconnected.  Then, you will need to adjust your device tree entry for the eMMC to only use 4 data bits.

One other thing to consider is that the boot mode only affects the interface that the ROM code within the AM3358 boots from.  Once the device has booted the SPL or U-Boot, the software can make a different decision about which interface to finish booting from.  For example, in the latest Linux images from BeagleBoard.org(TM), the microSD card is given preference over the eMMC in U-Boot when booting.  If a microSD card is inserted (and the BOOT button, i.e. S3, is NOT pressed), the device will boot the SPL and U-Boot from the eMMC but then boot the kernel and filesystem from the microSD card.  If the BOOT button is pressed, then all boot components are read from the microSD card.  Therefore, depending on what you are trying to do, it might be ok to use MMC1 for the eMMC and MMC0 for the microSD.

Please let us know if you have an additional questions.

 

[Erik Welsh]

Thanks for pointing out that the application note does not address how to connect the pins when not in use.  We’ll make sure to update the application note in the future.

To answer your question, when not in use:

• USBx_DM, USBx_DP, USBx_ID, and USBx_VBUS may be connected to ground or left floating
• USBx_CE should be left floating
• USBx_DRVVBUS may be left floating or may be used for the alternate GPIO function (see Table 4-2 in the AM3358 datasheet for more information)

Please let us know if you have any additional questions.

[Erik Welsh]

We would recommend that you refer to the OSD335x Design Tutorial Application Note.  Specifically, there is a section on USB:

https://octavosystems.com/app_notes/osd335x-design-tutorial/osd335x-lesson-2-minimal-linux-boot/osd335x-lesson-2-usb-circuitry/

Please let us know if you have any additional questions.

 

 

[Erik Welsh]

It looks like this was accidentally posted in two forums.  The answer to the question was in the other forum post:  https://octavosystems.com/forums/topic/inverted-eeprom-and-sd/

[Erik Welsh]

Glad you were able to figure it out.  Please let us know if you have any additional questions.

[Erik Welsh]

Have you checked the control signals (PMIC_PGOOD/PWRONRSTN, WARMRSTN, etc.) to ensure they have proper behavior?  Are you seeing a clock on the input?  Have you done a detailed analysis of what changed between the previous revision and this revision?

Unfortunately, without seeing the schematics, we can’t offer much guidance.  If you cannot share the schematics publicly on the forum, please email support [at] octavosystems.com and we can set up a secure way to send us the information.

[Erik Welsh]

First, you should check your network configuration settings to ensure that the adapter is configured correctly.  In Windows 10, if you go to “Settings” –> “Network & Internet” and select “Change adapter options“, this will pop up a new window with all of the adapters.  In your Network Adapters window, if you right click on the adapter for the board and select “Properties“.  In the center window of the “Properties” pop up, select “Internet Protocol Version 4 (TCP/IPv4)” and click “Properties“.  Generally, you should be able to use “Obtain an IP address automatically“, but sometimes windows will not provide an IP address on the proper subnet, so you can always select “Use the following IP address:” and enter “192.168.7.2” for the IP address and “255.255.255.0” for the Subnet mask.  Once you have made the updates, select “OK” and then “Close” to make sure the settings are applied to the system.

If that does not fix the problem, one other thing you should check is the “known_hosts” file in the the “.ssh/” directory (this may be a hidden directory usually found in the “C:/Users/<username>/” directory so make sure you can see hidden items which is a checkbox in the “View” menu of the File Explorer window).  The “known_hosts” file contains the key fingerprints used to authenticate the SSH connection and if something changes, this can get out of sync at which point SSH will refuse to connect to the host.  If you open up the “known_hosts” file with a text editor and delete the line for “192.168.7.1“, this will force SSH to prompt you to accept the new key fingerprint and you should be able to connect.

Please let us know if you have any additional questions.

 

 

[Author]

Posts