No announcement yet.

How to turn off heartbeep LED on 4 inch cape?

  • Filter
  • Time
  • Show
Clear All
new posts

  • How to turn off heartbeep LED on 4 inch cape?

    I have a 4 inch cape connected to a Beaglebone Black and even though I turn off the heart beep LED on my BBB, the one on the cape continues flashing. Is this programmed into the cape or does the cape read a GPIO on the BBB that I have missed? Thank you.

  • #2
    Hi Injunear

    The CAPE has no processor to program, it is simply a slave monitor to the BBB.
    Please refer to the Datasheet, you will find the Schematic Diagram at the back, and you will see the GPIO associated with the LED there.



    • #3
      Maybe this will help?



      • #4
        Thank you. Sorry. I was assuming that the heartbeat LED and the cape LED were from the same GPIO. It turns out that your LCD is using GPIO1-28 for its heartbeat signal. This is important to know because it means that even if I am not using GPIO1-28 on my BBB it is still running as output (which can be hazardous) unless I intentionally set it to input. Thank you for the quick response.


        • #5
          Hello again, James, (or anyone)

          I have so far been unable to stop the user LED on the cape from blinking. I have tried to configure GPIO1-28 for my own use in my Device Tree Overlay (DTO), but my overlay is not applied because that pin is configured in a previously loaded overlay. According to dmesg, that other overlay might be "gpio-leds-cape-lcd4.12".

          I have been unable to find where that comes from but it is contingent upon whether or not the LCD is connected. When connected, the LCD causes slot 3 to be loaded with:
          4D 4.3 LCD CAPE- 4Dcape-43T ,001A, 4D SYSTEMS ,BB-BONE-LCD4-01

          I presume that somehow the 4D cape DTO calls the gpio-leds DTO.

          I have been unable to find where these device trees are being called from, nor where their dts files reside. If I can find the dts files, I presume I can edit them to remove GPIO1-28 from their configuration.

          I apologize for bothering you again about this, but there is nothing on the net that I could find that tells me about the 4D Systems device tree overlay that is called when the LCD display is attached.

          Is anything loaded onto the Beaglebone Black from the LCD? A DTO, perhaps?

          But most fundamentally, how might I stop the user LED from blinking, and hopefully take advantage of it within my program? "It seems" I need to modify the 4D System DTO somehow.

          (Or, am I once again barking at the wrong tree? ;-) )

          Thank you very much for all of your kind assistance.
          Last edited by Injunear; 25 November 2015, 07:42 AM.


          • #6
            Hi Injunear

            There is no '4D Systems DTO'. We don't write the software which the capes use, our capes use the LCD cape support built into the kernel already. Circuitco made the LCD4 and LCD7 and our capes utilize the same drivers as they do.

            I would imagine that you would have to edit the kernel to change the purpose of those GPIO.
            There is nothing loaded into the 4DCAPE at all except for the contents of the EEPROM, which basically contains the 4D company information, and its like an LCD4 or an LCD7 which is what causes the BBB to load the appropriate driver from the kernel. The CAPE itself has no processor or any way to infulence the BBB other than the contents of the EEPROM, and the BBB uses that to know what to load. However to change what is being loaded I would imagine would require a kernel rebuilt with your customisations, unless it can simply be re-purposed after it is loaded.

            I will get one of our engineers to have a look and see if they can lend a hand on this issue.



            • #7
              Thank you for your quick response.

              I am curious about what is loaded from the LCD. Perhaps the engineer can make that clearer to me.

              Off hand, it would make sense to me for the "4D 4.3 LCD CAPE- 4Dcape-43T ,001A, 4D SYSTEMS ,BB-BONE-LCD4-01" DTO to be loaded from the 4DCape EEPROM, but if not, are you saying that it is built into the kernel?

              Did CircuitCo write the 4D 4.3 LCD CAPE firmware on your behalf? Did they put it into the BBB kernel?

              Ultimately, I guess I am trying to find out where the 4D 4.3 LCD CAPE DeviceTree firmware is coming from and how I can modify it.

              Thank you once again.


              • #8
                FWIW, attached is a screen shot of the 4D firmware loaded into slot 3. Click image for larger version

Name:	BBB Screen Shot.jpg
Views:	186
Size:	48.4 KB
ID:	49662

                As you would expect, that slot is empty when the LCD is not attached.

                Attached Files
                Last edited by Injunear; 25 November 2015, 01:39 PM.


                • #9
                  After looking at the screen shot more carefully, I can speculate that the first three fields of slot three come from the EEPROM of your LCD, and the actual DTO that is used is "BB-BONE-LCD4-01".

                  So, I guess I need to track down where "BB-BONE-LCD4-01" comes from.

                  Any further clarification or confirmation will be gratefully welcomed.

                  Thank you once again.


                  • #10
                    Hi again

                    BB-BONE-LCD4-01 is the Circuitco LCD4 CAPE reference I was talking about.
                    Circuitco made capes first and the drivers for their capes were put into the main stream kernel. We then just utilise this existing driver, as it is the same as what we would be using anyway.
                    In theory I guess if you made your own DTO or whatever it is that gets loaded, and change the EEPROM to load that instead, then that might work.

                    There may be an easier way to disable the LED though.
                    Did the link I posted in post #3 not help? I seem to recall about a year ago when I was playing around with one of our capes, I could make the LED do different things. Heartbeat, surging, CPU activity etc.



                    • #11
                      Thanks James,

                      The link discusses how to use the four LEDs which are on the BBB itself and I have been able to use them for some time. The issue is that the user LED on your cape gets its signal from P9-12, (a.k.a. GPIO1-28, a.k.a. GPIO60, etc).

                      Your "theory" ;-) about making my own DTO is what I have been doing. I load that into slot 7. It conflicts with the DTO in slot 4, so my next step is to find out how I can modify or override BB-BONE-LCD4-01.

                      I have yet to try to add "exclusive use" commands to my DTO. Perhaps that will override the DTO from slot number 4.

                      Since I will not be using the five user control buttons of your LCD in my final application, I will probably do that with all of them.

                      At the very worst, I can clip the pin on your LCD that goes to P9-12. The most important thing is to not have that "blinking" (read between the lines ;-) ) LED presented to the user. (I recon that will invalidate the warranty, huh? ;-) )

                      Thank you very much for the help.

                      Once again, your help has proved of far more value than many hours spent trying to track down the answer on the interweb.

                      (Perhaps adding to your website some kind of simple "hardware-software integration reference sheet" regarding your LCDs would save countless others countless hours trying to solve the same and similar problems. To start with, it could contain the answers to the questions I have posted these past few weeks. It would have saved me a week's worth of accumulated frustration and researching. I am not assigning blame. I am just offering a friendly suggestion. ;-) )

                      Nevertheless, I like your LCDs and find them very handy for my prototyping purposes.

                      Thank you.


                      It just saved me the trouble of rewriting the above.


                      • #12
                        I think I found the source file of the DTO your LCD4 uses.

                        I currently speculate that, along with your company data listed in the EEPROM of your LCD cape, it also includes a reference to the generic overlay “BB-BONE-LCD4-01”.

                        Unfortunately, “find -name BB-BONE-LCD4\*” shows nothing within the file system of my BeagleBone Black, so it seems the cape overlay is not being loaded at boot-up. (Thereby preventing me from editing it as I wish.)

                        From your comments, I am guessing that the BB-BONE-LCD4 overlay is compiled into the Debian system somewhere.

                        Having no idea how to compile a linux kernel (a lot of work to stop an LED from blinking), perhaps, I can edit BB-BONE-LCD4-01-00A1.dts to my preferences and save it as my own dts & dtbo. Then, I can change my uEnv.txt file to disable the standard BB-BONE-LCD4-01 cape and load mine instead.

                        All-in-all, I have spent two, or more, days just trying to stop the “blinking” LED on the LCD cape. (We cannot have it in our application.) It's a shame the necessary simple information is not available anywhere (that I could find) on the internet.


                        • #13
                          Hi again

                          As mentioned, we have nothing to do with the software that runs these. We were not part of its writing, don't know how it works exactly, or how to change these, so I'm doing my best to try to assist, but really it has nothing to do with us. We provide a hardware solution, the software is all open source and built into the release kernel.

                          If you will, think of us like Samsung who makes LCD's for PC's. We dont have any part to play from Nvidia or Microsoft as to what drives the monitor, we just display the content provided.

                          Yes the EEPROM does contain BB-BONE-LCD4-01. Bytes 58 to 73 of the EEPROM contain the 'Part Number' which is set to be the same as the Circuitco LCD4, so it loads the appropriate driver from the kernel.

                          There should be a way to disable this LED though.
                          One of our engineers will hopefully find a solution for you today, very busy yesterday.



                          • #14
                            Thank you very much. I understand that the software does not come from you. Knowing that "BB_BONE-LCD4-01" is stored in your EEPROM is helpful.

                            I sincerely appreciate the help you have offered. It has helped me a great deal to figure out how your LCD interacts with the Beaglebone. I have spent another 8 hours trying to track down these answers on the internet and, again, your help has proved more valuable than all of my googling.

                            If I ever figure out how to turn off that "BLINKING!" LED, I may return and leave a post so your other customers don't have to spend the "blinking" time I had to to turn off that "blinking" blankety blank LED.
                            Last edited by Injunear; 26 November 2015, 07:19 AM.


                            • #15
                              Hi Injunear,

                              For a listing of the available source files for the device tree overlays please refer to this link:


                              To produce the *.dtbo please use the device tree compiler. Something similar to the line below.

                              dtc -O dtb -o BB-BONE-LCD4-01-00A1.dtbo -b 0 [email protected] BB-BONE-LCD4-01-00A1.dts

                              All *.dtbo files are located placed in /lib/firmware directory.

                              Please note that the eeprom of your device is currently loaded with the infomation related to "BB-BONE-LCD4-01-00A1" firmware. This would mean that its either you change the content or un-mount the eeprom itself (this voids the warranty if still within specified period). or modify the related firmware and maintain the file name used by the device.

                              Also, please be advised that simply recompiling the device tree source file does not directly load the modification made to the source files. The initrd.img-3.8.13-boneXX file must be updated in order to implement the changes.