512-861-3400Log inCreate Account

Custom board in Limbo State

Forums › Devices › OSD335x-SM › Custom board in Limbo State

Tagged: , ,

Viewing 1 reply thread
  • Author
    Posts
    • May 29, 2019 at 4:17 am #8270
      Arish Shareefashare
      Participant

        Hi,

        We have built a custom board based on the BBBW using OSD335x-SM and TI’s Wilink module. We have fabricated over 100 boards and have used a patched version (Robert Nelson’s patch) of u-boot for overriding the EEPROM check. Later, we programmed the EEPROM with the board code for BBBW and this method has worked fine for us for the entire batch except for a couple of boards. We noticed that 2 boards encountered some issue when we tried to write values to the EEPROM from the serial console. The console froze in between and we reset the boards to repeat the process. After restarting the boards, nothing was printed on the serial console. To ensure that the board was otherwise fine, we removed the SD card from the slot and turned the board on. It printed a continuous string of ‘C’s which is indicative of a live processor.

        To dig further into the problem, I downloaded a u-boot-spl.bin-am335x-evm to boot via UART. I sent the bin file via Teraterm in XMODEM mode and ended up with the following error message on the console:

        To understand further, I tried the UART booting on two more boards – one with EEPROM unprogrammed and the other which is correctly programmed with the BBBW board code. The unprogrammed board showed an error saying that the ‘magic number’ was missing, which is expected. The programmed board did not show any error and waited for the u-boot.img image by printing string of ‘C’s.

        Based on the above experiments, I suspect that the two boards which are stuck in a limbo state might have a wrong/incomplete version of the board code programmed via serial, possibly due to a loose connection, but what is surprising is that the patched version of the u-boot is supposed to ignore the board code or fool the board into believing it is a BBB. Am I missing something here? Can you suggest some procedure to revive the boards from this state? I do not have physical access to the I2C lines or the USB bus.

        Thanks for reading and appreciate any help in solving this issue.

        • This topic was modified 5 years, 5 months ago by Arish Shareefashare.
      • May 30, 2019 at 12:01 pm #8286
        Neeraj Kumar Reddy DantuNeeraj Dantu
        Moderator

          Hey ashare,

          One possibility is a non functional I2C interface between the processor and the EEPROM. The applied patch linked above checks if the EEPROM is dead(https://github.com/trini/u-boot/blob/master/board/ti/common/board_detect.c#L287) and that might be causing u-boot to not detect the board as a blank EEPROM board. You could bypass the check in the function by hard-coding the board detection process as shown in section 4 of the EEPROM App note(https://octavosystems.com/app_notes/osd335x-eeprom-during-boot/).

          You can also try a readily available blank image from https://rcn-ee.com/rootfs/bb.org/testing/2018-10-07/stretch-iot/.

          Please let us know if that helps or if you have more questions.

          Best,

          Neeraj

          • May 30, 2019 at 12:43 pm #8300
            Arish Shareefashare
            Participant

              Hi Neeraj,

              Thank you for your reply. Just to avoid confusion, let me make it clear that I have followed section 4 of the EEPROM App note and have created a version of u-boot which proceeds booting with a blank EEPROM. Hence my reference to Robert Nelson’s patch in my initial post. Are you saying that before detecting the I2C as blank the program might be probing the line and since there could be a possibility that the I2C link between the EEPROM and the processor might have gone bad, the program halts the boot? I can try to completely remove the detection code from u-boot. Can I use the blank image in the link you provided to accomplish the above? I will check and report back soon.

              On the same note, I am curious to know why the I2C link would go bad on a new chip like this if at all that is the case. Have you or any of your users encountered such an issue before?

              Thank you.

            • May 30, 2019 at 4:34 pm #8329
              Neeraj Kumar Reddy DantuNeeraj Dantu
              Moderator

                Hi ashare,

                Apologies for the confusion. Section 4 offers 2 methods for bypassing the EEPROM check. In 4.1, it is shown to be done by changing the contents of the function “board_is_bone_lt”. In section 4.2, the patches you referred to are used. I was referring to the hard-coding method described in section 4.1.

                If you are using the patched version of u-boot, the function “board_is_blank_bone_lt()” in  https://raw.githubusercontent.com/RobertCNelson/Bootloader-Builder/master/patches/v2018.03-rc1/0002-NFM-Production-eeprom-assume-device-is-BeagleBone-Bl.patch should return true. Going through this function, it looks like there is a check on whether the EEPROM interface is working. If the check returns false, u-boot might not be able to advance to the board initialization. In addition to that, you mentioned that you encountered a failure in the middle of the programming of the EEPROM. At this point, this is just a theory. If you can try the hard coding method described in section 4.1, we should be able to find out whether this is the failure point.

                We have not encountered an issue like this before. It’s important to keep in mind that this is a theory based on u-boot behavior and there might be something else causing the issue. Please let us know how your debugging efforts go!

                Best,

                Neeraj

              • May 31, 2019 at 4:38 am #8352
                Arish Shareefashare
                Participant

                  Neeraj,

                  I followed the method outlined in 4.1 and I was able to boot the board. Later, I used the u-boot command line to write the correct values in the EEPROM. I guess the EEPROM was corrupted in the first attempt which prevented booting because the corrupted board code was not defined anywhere in the u-boot code. Robert Nelson’s code only adds a blank EEPROM into the list, does not completely avoid the check as you pointed out. Thank you for helping.

                • May 31, 2019 at 9:49 am #8353
                  Neeraj Kumar Reddy DantuNeeraj Dantu
                  Moderator

                    Thanks for the update! Happy to help

                    Neeraj

              • Author
                Posts
              Viewing 1 reply thread
              • 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.