512-861-3400Log inCreate Account

Custom board, first boot – UART0 baudrate 'off'?

Forums › Devices › OSD335x-SM › Custom board, first boot – UART0 baudrate 'off'?

Viewing 4 reply threads
  • Author
    Posts
    • June 26, 2018 at 3:38 pm #5815
      Dusty
      Participant

        Hello,

        we started bringing up our custom board (OSD3358-SM, similar design as PocketBeagle, plus eMMC).

        We confirmed DC voltages first, which I think look good:

        We then connected a serial terminal (115200 baud, 8N1) to UART0 (no uSD present, SYSBOOT[4..0]=11100) and periodically receive the character ‘Á’ (expectation: character ‘C’). The same serial setup gives the expected result (‘C’) on the PocketBeagle board.

        Then we tried booting our board with a uSD card with the EEPROM board ID u-boot patch applied according to post 4733.

        The result is lots of garbage on the serial terminal.

        I then checked the serial signal on the oscilloscope. The voltage level looks good (3.3V), but the bit length is 7us, which means a baud rate of about 140900.

        I set the serial terminal manually to 140900 baud and indeed see regular console output. I copy the boot console output below, but I don’t think that this is related to the image, since now (at 140900 baud) also the character ‘C’ appears as expected when starting up without Linux image.

        The serial circuit is straight from balls A12, B12 to the FTDI board, so not much that can go wrong here…

        What can cause the baud rate to be off like this?

        Thanks,
        Dusty.

         

         

      • June 26, 2018 at 4:04 pm #5816
        Neeraj Dantu
        Moderator

          Dusty,

          2 things here:

          1. Please verify that the crystal clock input is 24MHz using an oscilloscope. You can probe OSC0_IN(P16) or OSC0_OUT(N16)

          2. Please verify the SYSBOOT configuration on SYSBOOT[15:14]. These 2 most significant bits in the SYSBOOT pins set the clock speed configuration. So, a mismatch between the configuration here on the SYSBOOT pins and the clock input on OSC0_IN can cause a different clock to be set on the UART interface which by default is at 115200 setting. SYSBOOT[15] (MSB) should be pulled down and SYSBOOT[14] should be pulled high for the 24MHz setting. Please see ‘Table 26-7. SYSBOOT Configuration Pins’ in AM335x Technical Reference Manual (https://www.ti.com/lit/ug/spruh73p/spruh73p.pdf) for SYSBOOT configuration options.

          Neeraj

        • June 26, 2018 at 4:58 pm #5817
          Dusty
          Participant

            Thank you Neeraj.

            1) Both OSC0 pins show a nice 24MHz signal. The p-p voltage on OSC0_OUT is about 800mV, on OSC0_IN about 50mV. We’re using the 7A-24.000MAAJ-T crystal.

            2) SYSBOOT[15] is pulled down with 100k, and SYSBOOT[14] is pulled up with 100k.

            And by checking this I probably just answered my question…:

            SYSBOOT pins [15] and [14] (as well as SYSBOOT[11..8]) are also connected to other hardware as GPIO (or rather MII0_PRU), due to the lack of other pinmux options. The plan was to hold that other chip in reset with a pulldown on it’s reset# line, until the OSD3358-SM actively takes it out of reset by setting this GPIO output to high after booting.

            I guess the other chip still pulls SYSBOOT[14] too far down, although held in reset. SYSBOOT[15] shows 2.1mV (OK) and SYSBOOT[14] has 648mV (not OK).

            I looked into buffer / line driver options to isolate the external signal during boot when designing the board, but ‘hoped’ the reset trick will work without further hardware.

            Do you have any (proven) recommendations for this issue?

            Thanks again,
            Dusty.

             

             

          • June 26, 2018 at 5:16 pm #5818
            Neeraj Dantu
            Moderator

              Dusty,

              Apart from isolation, you could try having a stronger pull up on SYSBOOT[14]. Looks like a 10K instead of the 100k pull up would push the pin over the digital threshold. However, you will need to make sure that the stronger pull up does not cause any timing issues on the communication signal on the pin and you would have to live with the additional power dissipation on the pin.

              Neeraj

            • June 27, 2018 at 9:51 am #5822
              Dusty
              Participant

                Thanks Neeraj,

                the 10k pull up helped to recognize the correct SYSBOOT bits and the system boots with 115200 baud.

                The next steps will tell if the stronger pull up messes with the external signal after boot. If that’s the case (or maybe anyway), we’ll add buffers for the shared signals on the next board spin…

                Dusty.

            • Author
              Posts
            Viewing 4 reply threads
            • You must be logged in to reply to this topic.

            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.