Aedan Cullen

Forum Replies Created

Viewing 7 posts - 16 through 22 (of 22 total)
  • Author
    Posts
  • Aedan Cullen
    Participant

      It may be that the UART0 RX signal is accidentally floating, or something is pulling it to an indeterminate logic state. To check, try connecting a strong pull-up resistor (the relevant power rail is board-dependent of course) and see if the issue still appears.

      It could be helpful to know whether you’re using an off-the-shelf or custom board. (For instance, by “nothing connected”, do you mean there are absolutely no components on the board connected to the RX pin?)

      in reply to: OSD32MP1-RED UART communication #12214
      Aedan Cullen
      Participant

        That last line (“STM32MP>”) at the end is the U-Boot interactive prompt. It has stopped just before loading the kernel, presumably because it thinks it was interrupted by a keypress (“Hit any key to stop autoboot”). Since you see this when connected to UART, yet when not connected it progresses past here and you see the kernel heartbeat, something might be wrong with the TX side (PC/RPi to OSD32MP1) of your UART that is causing some character to be accidentally/continuously sent. This would also explain why your keyboard input is not working properly.

        Try using only the RX side of the UART (OSD32MP1 to PC/RPi) and leaving TX unconnected.

        in reply to: UART/Debug access via USB-C port on OSD32MP1-RED design #11922
        Aedan Cullen
        Participant

          After booting, the common way to get a console over USB is to configure it as a device (a USB “gadget” in Linux) using RNDIS in order to get Ethernet, and then SSH in from there. This is totally an OS-level thing and has nothing to do with boot. For example, OpenSTLinux configures this by default. This is of course convenient for software development after boot, but will not provide you a console earlier in the boot process. I am not aware of a way to get an earlier console over just USB, and I would think it is not very advisable to design a board without access to UART (at least on test pads) for debugging during the boot process.

          in reply to: OSD32MP1-BRK booting to DFU mode? #11789
          Aedan Cullen
          Participant

            It seems to me that an intermittent issue with the boot device would cause the boot ROM to fall back into serial DFU mode even if the boot pins are strapped correctly. According to ST’s ROM code overview on their wiki, if the FSBL cannot be loaded, in basically every configuration you will fall through to serial boot (UART or USB DFU). So the following things come to mind:

            – Have you tried a different SD card?

            – For issues with a custom board, have you checked the SD interface with a scope or logic analyzer to see if it looks like the ROM is trying and failing to load the FSBL from the card?

            – Especially with a custom board, what do you see on the UART when you are trying to boot?

            According to that wiki page, there’s no way to instruct the device to exit DFU mode once you’re there. You have to do a reset and get the ROM code to first read the correct strap pins (which I would bet is probably working fine), and then load the FSBL successfully (which I believe could fail due to various minor issues with the SD/MMC device itself or its interface).

            • This reply was modified 3 years, 2 months ago by Aedan Cullen.
            in reply to: Exception during first boot #11052
            Aedan Cullen
            Participant

              I remember seeing exceptions like this a while ago as a result of bad devicetrees (with incorrect syntax/semantics and such). I assume you’re using a custom device tree as well, so that’d be the first thing I would check. However, I’m not knowledgeable about devicetree debugging and I would suppose that there are other causes of a message of this sort, given how generic it seems to be.

              • This reply was modified 3 years, 11 months ago by Aedan Cullen.
              in reply to: Check or change CPU speed from Linux #10776
              Aedan Cullen
              Participant

                Just came across this thread – this patch might be relevant: http://u-boot.10912.n7.nabble.com/PATCH-v2-0-9-stm32mp1-use-OPP-information-for-PLL1-settings-in-SPL-td413606.html

                Of course, if you feel like breaking the rules you can directly tweak PLL1 settings in the device tree. Last year I checked my STM32MP157C-DK2 just for fun: it was stable up to 1.05GHz without any change to the core voltage.

                in reply to: Procedure for configuring VDD=1.8V #10676
                Aedan Cullen
                Participant

                  Thank you, that makes sense. The only thing I am not sure about is the initial configuration of Buck3. If the SiP is on a board with VDD tied to VDDA1V8_REG, at first wouldn’t 3.3V be applied to VDDA1V8_REG as that is the default setting of Buck3?

                Viewing 7 posts - 16 through 22 (of 22 total)