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.

boot issue on customed board

Other Parts Discussed in Thread: OMAPL138, OMAP-L138

hi

we have a customed OMAPL138 board.

The board (let's call it BoardA) was soldered with the wrong type DSP(OMAPL138ZWTD4E), so we had to remove the wrong DSP and re-solder the right type DSP(OMAPL138ZWTD4).  Because of the worry of weak solder, after re-solder, we confirm the PCBA good status with its UART output "BOOTME".

we want to download a user bootloader into the internal ram with UART by OMAP-L138_FlashAndBootUtils_2_40 tools to boot the board .

the problem is we can download user bootloader sucessfully to BoardA by UART,but when BOOTROM jump to the user bootloader, it can not even output a simple character by UART.

 we did these works to check the board status:

1)considering the possibility of weak solder, we try to power down all other modules not needed in minimize system ,like DDR, SPI,.., just power on the PLL and UART we used, by setting PSC0 and PSC1, the result is same.

2)we check the downloaded image in PCBA's ram, they are exactly the same thing we download

3)we check the board status by debug GEL, it seems PC stay in user boot loader area.

4)we compare the peripheral modules stat after out bootloader running with BOOTROM running, keep they are same, the result is not changed

5)we also check the UART registers, find that the UART registers are not the data we want

6)if we do not put data on UART transmit buffer, we can blink a LED normally.

Now we are very confused, why this minimize image can not set UART correctly and output characters? Anyway, BOOTROM can communiate with host PC by UART successfully.

can someone provide some idea or advice on this weird problem?

if my description is not very clear and detailed, i can provide more detail.

thanks in advance

Jie

 

 

  • Hi

    it is still I.

    I guess my last post is not very enough.

    I want to add that all the communication stop in the scene below (with italic)

     

    -----------------------------------------------------
       TI Serial Flasher Host Program for OMAP-L138
       (C) 2013, Texas Instruments, Inc.
       Ver. 1.67
    -----------------------------------------------------


          [TYPE] Global erase
        [TARGET] OMAPL138_LCDK
        [DEVICE] SPI_MEM
     [SPI Block] 0


    Attempting to connect to device COM1...
    Press any key to end this program at any time.

    (AIS Parse): Read magic word 0x41504954.
    (AIS Parse): Waiting for BOOTME... (power on or reset target now)
    (AIS Parse): BOOTME received!
    (AIS Parse): Performing Start-Word Sync...
    (AIS Parse): Performing Ping Opcode Sync...
    (AIS Parse): Processing command 0: 0x58535901.
    (AIS Parse): Performing Opcode Sync...
    (AIS Parse): Loading section...
    (AIS Parse): Loaded 8828-Byte section to address 0x80000000.
    (AIS Parse): Processing command 1: 0x58535901.
    (AIS Parse): Performing Opcode Sync...
    (AIS Parse): Loading section...
    (AIS Parse): Loaded 132-Byte section to address 0x8000227C.
    (AIS Parse): Processing command 2: 0x58535901.
    (AIS Parse): Performing Opcode Sync...
    (AIS Parse): Loading section...
    (AIS Parse): Loaded 964-Byte section to address 0x80002300.
    (AIS Parse): Processing command 3: 0x58535906.
    (AIS Parse): Performing Opcode Sync...
    (AIS Parse): Performing jump and close...
    (AIS Parse): AIS complete. Jump to address 0x80000000.
    (AIS Parse): Waiting for DONE...
    (AIS Parse): Boot completed successfully.

    Waiting for SFT on the OMAP-L138...

     

     

  • Thanks for your reply, Rahul.

    we did customize the serial flash and boot utilities as the wiki link's guide.

    the new update is that we can locate the issue on weak re-solder now. In the first PCBA, we used the wrong DSP (OMAPL138BZWTD4E) and re-soldered with the right DSP(OMAPL138BZWTD4). This time we build a new PCBA without any change except with the right DSP. Now it works very smoothly.

    Now we are very curious the stability of BOOTROM in the chip. If the user bootloader can not driver UART under the unstable conditions caused by weak solder, why BOOTROM can do it?  Is there any trick here?  Any clue helping locate the position of the weak re-solder pins? the ROM ID of our chip is d800k008.

     

    Thanks

    Jie

     

  • Are you sure your secondary boot loader is doing the right pin mux configuration and turning on the PSC corresponding to the UART port? Did you load and run your secondary bootloader over an emulator and see if that resulted in any output on the serial port? If did see a BOOTME on the serial port there is no reason why your secondary bootloader will not be able to communicate using UART unless the PINMUX, Clocks or the power domain settings do not match.

    I don`t think the boot can be used for locating the weak re-solder pins. You can create simple loopback UART test cases that you can load and run over the emulator and then measure the output on the RX, TX  pins and trace them back to OMAPL138 pins to see where the issue lies.

    Regards,

    Rahul