SD Card Boot Issues On Custom Board

[Alvan Alam]

Hello Everyone,

I am having issues booting to my custom PCB that uses the OSD3358-SM-ISM. I currently get the attached output from the UART0 serial console when booting from SD card. These U-Boot SPL messages are outputted indefinitely and the board gets stuck at this stage. The image I used to get this output is from this forum: (https://octavosystems.com/forums/reply/4880/), and I get similar output using the kubos linux images. I also get the output of “C”s from the serial console after programming the eeprom. I am really not sure why this behaviour is occurring and what might be causing it?

Any help on how I could debug this issue would be appreciated. My PCB design can be found on github here: https://github.com/SkCubeSat/radsat-v1/tree/main

 

Attachments:

1. 

   image-1.png
   

2. 

   image.png
   

[Neeraj Dantu]

Alvan,

Here are some pointers:

1. If you need to program the EEPROM, you will need to connect the EEPROM_WP(write protect) to GND. Can you verify that the EEPROM was programmed after you write to it? If SPL is running into an error, presumably because of a blank EEPROM, the watch dog timer may be resetting the board, resulting in the boot cycling

2. From the design repository, it looks like AC input line for OSD3358 SiP could be a bottleneck for current because of trace width. Are you powering the device through USB input or the AC input?

3. You can generate custom images using the beagle SDK for OSD3358-SM-RED here: https://github.com/RobertCNelson/omap-image-builder/tree/master/octavo including images that boot with blank EEPROM

Best,

Neeraj

[Alvan Alam]

Hey Neeraj,

1. I have been following proper procedure to program EEPROM including grounding the EEPROM_WP. After I write to it I am able to immediately read back what was written but I can double check this. I have also followed section 4.1 from here https://octavosystems.com/app_notes/osd335x-eeprom-during-boot/ and generated an image which hard code the board id to a beaglbone black, but this image gave the same output as above. I tested this same image on an OSD3358-SM-RED and it worked fine, which leads me to believe the EEPROM is not an issue. I will try generating some of the images you suggested and get back to you.

2. I have been powering the device using the AC input, do you think this could cause issues or potential damage to the board?

Thanks,

Alvan

[Neeraj Dantu]

Alvan,

The trace width to 5V AC input could be an issue due to in-rush(~1500mA). There are 3 traces 5 mil each, I am not sure whether that is the issue.

I did notice on 2nd look that 3.3V is also needed from the connector H2. Is this being supplied as well? Sequencing wise, this 3.3V should come ON with SYS_VOUT.

The messages you shared in the screenshot, do they appear immediately one after another? or does the board take ~30 sec for each header message print? If it is immediate, it is more likely that there is an issue with the Power system as PMIC tries to power up immediately after 1 sec or so of failure. If it is longer, SPL(first stage bootloader) might be running into problems resulting in a software related fault, which resets the board because of watchdog timer expiration.

You can try using the USB input as it looks like you have brought it out to a big via and it has better routing.

Let me know of progress in debug.

Best,

Neeraj

[Alvan Alam]

Hey Neeraj,

I have some good news, as I was able to successfully boot my board! After using the USB input the board was able to boot properly. I believe it is as you said that there is a power issue with the board as the messages I got in my original log did appear immediately one after the other when powering via AC input. Would the solution to fix the AC input be to increase the trace width?
Note: yes I have been supplying 3.3V separately via the H2 connector.

I also have one other inquiry. After flashing linux onto my board I found one time when starting up the board while it is held in reset it would get soft locked in the reset state even after I release the reset button/WARMRSTN. The way I fixed this was by switching back to powering via AC input, getting the same output I got previously, and then switching again to usb input. I am wondering if this soft locking is normal behaviour?

Any other input you could give on improvements to my pcb design would be greatly appreciated. Thanks for your help in this matter.

Alvan Alam

[Neeraj Dantu]

Good to hear!

If the device is being powered down and powered back up, that should reset any fault that has occurred previously, unless somehow the PMIC internal state machine was still powered. See Section 8.4 of the PMIC datasheet(https://www.ti.com/lit/ds/symlink/tps65217.pdf) for the state machine.

I will look at the layout to see if I have additional inputs.

Best,

Neeraj

[Author]

Posts