Actions
  • Author Author: pchan
  • Views 92833 views
  • Downloads 58919 downloads
  • Likes 20 likes
  • Comments 76 comments
Related
Recommended

Raspberry Pi 3 Model B GPIO 40 Pin Block Pinout

Graphic showing the GPIO pin breakout on the Raspberry Pi 3 Model B.

 

If you're looking for the new Raspberry Pi 3 Model B+ then you can find that here: Raspberry Pi 3 Model B+ GPIO 40 Pin Block & PoE Header Pinout

                                                                                                             
NEW! Raspberry Pi 3 Model B
Frequently Asked Questions Comparison Chart Technical Specifications
Unboxing Video Pi3 Video Arcade Project
pchan
  • in reply to clem57

    Looks like a new firmware in place 7 hours ago:

     

     

    The order in cmdline.txt and config.txt shouldn't make any differences. DT overlays are applied in order, but provided the overlays don't overlap then there shouldn't be a problem.

    If you are seeing garbled serial port data when the core frequency is fixed then it suggests that the CPU is being throttled due to over-temperate or under-voltage (but that won't happen if you have pegged the core at 250MHz). A 2.5A power supply is recommended.

    I've just completed a firmware mod that improves the serial port alias handling:


    1) It will search for any existing "serial0" in the DT, allowing the pi3-disable-bt alias to also disable the remapping.
    2) It now searches for "=serial0", "=ttyAMA0" etc. instead of "config=...", so it will work with "kgdboc=serial0,115200" etc.

     

    Clem

  • in reply to shabaz

    So turbo works as a stop gap measure. Thanks! They are doing some inky things under the cover with the timing of the UART.

    Clem

  • in reply to clem57

    Incidentally, the MCP2221 based USB-Serial adapter ( Building a USB UART Serial Adapter  ) behaved admirably at the strange 72000 baud speed! image I thought it would not have accepted setting to this speed, but it worked.

  • in reply to cstanton

    Hi Christopher,

     

    It was a bit confusing what the fix will be, but it sounds from that and the pi thread that it is likely that either forcing turbo (1.2GHz) or setting core freq to the minimum of 250MHz solves this. I wish there was some block diagram that explained the relationship, because I would have thought that for max aggregated throughput the CPU speed would have been 1.2GHz and the core_freq to the maximum of 400MHz would have been the combination to go for, so that the GPU (and anything else than hangs off the core_freq clock) would be running at top speed, as well as the CPU at the 1.2GHz speed.

    I suspect they will set core_freq to 250 for the fix, so that 1.2GHz speed isn't used for the CPU all the time, but I wonder if this means that GPU performance remains the same as Pi 2 then. I hope this isn't the solution, to make people choose between a high speed GPU or a working console/UART!

     

    Another odd thing was that I tried typing core_freq=400 into the config.txt file (I also had force_turbo=1 in there too), and when I examined GPIO toggle speed, I expected to see the jitter fall on 2.5nsec intervals, if the GPIO was clocked from the core_freq clock. However I saw jitter at 4nsec intervals (i.e. 250MHz). I wonder if that is from a separate clock inside the BCM.., or if the core_freq=400 didn't take effect. I don't know of a way to see what the core freq clock is from the command line unfortunately.

  • in reply to shabaz

         Got a favor to ask about the UART. Can you try this:

    You can also get around the issue by adding force_turbo=1 to config.txt

         and report if this work around solves the problem?

    Thanks buddy,

    Clem