• State
  • Locked Locked
  • Replies 3 replies
  • Subscribers 99 subscribers
  • Views 386 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

SPI boot problem for 2nd OMAPL138

Duy-Ky Nguyen88210
Expert 2250 points
Other Parts Discussed in Thread: OMAPL138

Hello,

I have 2 OMAPL138 on our prototype.

I'm able to load flash and boot only one of them.

For the other one, I have

1) Able to do flashing both boot and app images similar to the 1st chip

2) Able to run BOOT code under debugger and it loads and runs APP out of Flash

3) But NOT able to boot by itself, even with correct setting boot pins [7:0] 0000-0110 as the 1st chip

After power up, I see chip select activated in the 1st SPI flash, but not the 2nd one. Needless to say that the 2nd SPI flash chip select is activated if I use Debugger to run BOOT code to load and run APP code from 2nd SPI flash

You have any idea for me to look at ?

Thanks,

~Duy-Ky

  • 0
    Intellectual 485 points

    You say, that you have a prototype... So, is it that you have your custom board and not the one TI provides?

    Are you using the same instances of SPI controller one each of the OMAPL138? If yes, then can you check if the hardware is correct - no forced pin pull up/down on SPI pins (CLK, CS and DATA lines).

    If you are using different instances of the SPI controllers on each of the OMAPL138 (for example SPI0 on one and SPI1 on the other), have you made sure that the PINMUX, PSC, BASE addresses etc are correctly set according to the instance? Given that with the debugger things are working fine and not standalone bootstrap, means that you have GEL file updated correctly and not the boot code

    Note that boot code is tightly copuled with he instance of SPI being used. You may have to take care of modifying it if you are changing the controller instances or any thing that is different from the EVM on your custom board

    Hope this helps..

    Regards,

    Madhvapathi Sriram

  • 0 in reply to Madhvapathi Sriram
    Expert 2250 points

    Hello,

    Our prototype is based on PD Logic Eva board and I believe it's the only Eva brd for OMAPL138

    Our prototype  has 2 duplicate circuitry of OMAPL138 on board

    The boot code runs on Eva brd, and only one OMAP, even the second one has the same circuitry as the first.

    The same binary runs only on the Eva brd and the 1st OMAP, but not the second one running after booted up in stand-alone mode

    However, all three Eva brd, and 2 OMAP are going well under debugger mode with exactly the same boot code and app code

    Even the same boot mode setting 0000-1100 for both OMAP, but the second OMAP has no SPI_CS activated after power-on, while the first OMAP has its own SPI_CS activated

    Per datasheet, all I can do is to set the right setting for boot mode and I expect SPI_CS acitvated after power up, but it's NOT

    Any idea ?

    Thanks,

    ~Duy-Ky

  • 0 in reply to Duy-Ky Nguyen88210
    TI__Genius 17370 points

    is your problem solved.

    regards

    Baskaran