• State Resolved
  • Locked Locked
  • Replies 7 replies
  • Answers 1 answer
  • Subscribers 101 subscribers
  • Views 219 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

OMAPL138B-EP: Boots from UART, but not from SPI-FLASH

Stefan sals
Prodigy 10 points
Part Number: OMAPL138B-EP
Other Parts Discussed in Thread: OMAP-L138

Hello,
we just produced new Boards with OMAP-L138 Rev. 2.3 (marked with E), these are the same Boards as we produced
previously with Rev. 2.1/2.0 (marked with B).

We set two Jumpers to set BOOT[3] to Low and Boot [4] to High; Boot[2] is High and all other are Low via R=1,87k -> Boot from UART2
We initialize the Boards by connecting via UART to a PC, booting the OMAP from UART by sending an AIS File with an U-Boot System via AIS File.
Then we download this AIS file to RAM and write it to Flash, writing U-Boot-Env-Args to Flash and finally load and write a Linux Kernel t o Flash.

Then we remove the Jumpers BOOT[3] to High and Boot [4] to Low (via R=1,87k) -> Boot from SPI1 Flash

The old Boards boot from SPI1 Flash now, but the new Boards (with Rev. 2.3 OMAP) did not... and that is the problem!

What we further tested until now:
- setting to boot from UART, load AIS File via UART and get our U-Boot-system, which loads Linux Kernel Image from Flash and start it.
  so Flash is working, we can see also the previously written U-Boot Environment Arguments.

- boot from Flash selected: measuring Flash CLK-Line: no Clocks to see (but to see while writing Data to Flash..)

- pull /TRST low and than /RST for a short: in UART-Bootmode we see the BOOTME, but in SPI1-Flash-bootmode nothing happens (also no CLK)

- reducing R=1,87k on BOOT[3,4] by a parallel R=750R; did not change anything

- try to find some hints in the docs, google, FAQ...

Now i run out of ideas and would be very appreciate for any hint..

  • 0
    TI__Guru 59996 points
    Stefan sals said:
    we just produced new Boards with OMAP-L138 Rev. 2.3 (marked with E), these are the same Boards as we produced
    previously with Rev. 2.1/2.0 (marked with B).

    Can you re-work/swap an L138 from a working board into your non-working board and see what that does?

    Regards, Andreas

  • 0 in reply to Andreas Dannenberg
    Prodigy 10 points

    I cant do it by my own - and its very expensive since you have to reball the BGA.
    So this might be a last try (or set a new processor onto an old board..). In the moment
    i try to install CCS to debug and read bootmode register (which tells me what OMAP is configured to boot from)

  • +1 in reply to Stefan sals
    TI__Guru 59996 points
    Stefan sals said:
    I cant do it by my own - and its very expensive since you have to reball the BGA.
    So this might be a last try (or set a new processor onto an old board..). In the moment

    Understood.

    Stefan sals said:
    - pull /TRST low and than /RST for a short: in UART-Bootmode we see the BOOTME, but in SPI1-Flash-bootmode nothing happens (also no CLK)

    So no clock at all during the SPI flash boot attempt, even nothing right after the reset release? (Should look at reset release and SPI CLK at the same time using an DSO, to make sure).

    The fact that you could program/access the SPI flash before the boot attempt means the processor pins/signals betweeen the two should be in good working order. If there's really no CLK signal coming out during the boot that means the ROM code isn't even attempting it, which could well be a boot mode setting issue, as you are already started pursing yourself.

    I'd look at all signals, etc. that are involved in the boot mode selection on that device, and re-measure those to make sure they have the required logic level at startup. Perhaps some subtle/undetected component change during your latest board run causes an issue.

    Regards, Andreas

  • 0 in reply to Andreas Dannenberg
    Prodigy 10 points

    I'll measure all regarding Pins, Measuring complete first boot time..
    .. first i have solder many cables to the board...
    Hopefully i can see then what goes wrong..

  • 0 in reply to Stefan sals
    TI__Guru 59996 points

    Hi Stefan, sounds good, let me know what you find.

  • 0 in reply to Andreas Dannenberg
    Prodigy 10 points

    Hello,
    i found out that... it was a typo...
    After measuring all the signals and everything was fine, but the Flash answers with a 0x00 data word i checked the Flash content.
    This time i read data at Adr. 0x00 and compare it with date loaded via TFTP - and it was different,.. there is really 0x00 written inside the Flash.

    And then i saw the typo:
    In my textfile i collected U-Boot commands to install the software: Download images to RAM Address to 0xc0700000 and write to flash.
    The line for writting the linux kernel image was ok (and this part was working) but the in the command for writing AIS file the was a "0" to much:
    -> sf write 0xc07000000 0 0x40000
    So the sf write command simply read from an empty memory address..

    Now everything is working, Thanks for support!

  • 0 in reply to Stefan sals
    TI__Guru 59996 points

    Thank you for closing the loop, glad you got this sorted out!

    Regards, Andreas