• State
  • Locked Locked
  • Replies 3 replies
  • Subscribers 97 subscribers
  • Views 276 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.

Bringing up an OMAP3530, Trouble with Booting

David S.
Prodigy 90 points

Hello,

I used the Mistral EVM-Board (EVM2, new revision) since 1 week, earlier I used the old revision EVM(1) for half a year using the BSquare Board Support Package with EBoot and WinCE6R2. It fits good to our planned product. I work a lot with Platform Builder and change WinCE to our needs.

Now our own Hardware is here (only a few changes in schematics, very similar to the EVM reference design) and I have big troubles to boot it. Maybe I understand something wrong, so I hope, somebody can help me here. The OMAP runs, I can use it using a Lauterbach JTAG debugger to transfer a little test binary into it and debug it line-by-line. It works. Or I can see and change the registers..

We decided to use sys_boot[5] = 1 and sys_boot[4:0] = 0b01111, so it should use the boot order: USB, UART3, MMC1, NAND. This combination works also on EVM2 board (earlier I used other combinations for direct SD or USB boot, but ok). So I could write the compiled EBoot.raw-image with the EVMFlashTool (new v2, v1.2 has troubles with the new EVM2 board, but works well half a year with my old EVM1 board). Then I could boot from flash and transfer a NK.bin using the EBoot USB-mechanism (RNDIS Virtual LAN, Boot.me packets, Visual Studio Attach Device) and burn the NK into the flash to use it. This works good on EVM board.

Sadly our board don't boot via USB, MMC or something else.  The first time I start a USB boot (EVM board) my windows detect the device and ask for the driver. I installed it (delivered by EVMFlashTool) and it works. Our board said nothing. And the EVMFlash endlessly waits for the starting signal after reset after I push the download button.

Is there anything missing on a brand new factory builded OMAP? Or is this booting feature in internal ROM and I can't do anything wrong - the OMAP will simply do it.

 

With the Lauterbach Debugger I can see the CONTROL_PADCONF-Registers. The associated registers for USB (STP, NXT, DATA), UART and MMC1 are using MuxMode7, which means SafeMode. On the EVM board it is MuxMode0. I can change the registers using the Debugger, but on a reset the OMAP switch back to the default 7. I think this is the problem, that the OMAP don't use USB, MMC1 or UART.

But how can I fix it to get my bootloader into the flash (or simply boot from a known-as-good SD card) so I can bring up my peripherals?

I hope somebody could help me.

Thanks in advance.

David.

  • 0
    Genius 3685 points

    Hi David,

    I hope you already fixed your problem. In case not, try to check the Tracing Vector, which tell you what the OMAP have tried to do for booting. More info abut the Tracing Vector can be found in the TRM table 25-9 and chapter 25.4.9...

    The OMAP3 boot-loader is in ROM and the only stuff you need to do is configure the SYSBOOT pins correctly and applying power and everything is then expected to work on it's own from here. When setting the pins are you pulling the hard or through a resistor (and in given case, what the value of this resistor?)?.

    With respect to the Pinmuxing, I'm 99% confident that the ROM code set balls back in safe mode in case it decides this is the wrong way to go for booting. You therefore can't use this to try to validate what the ROM code has actually done - Use the Tracing Vector instead.

    Best regards - Good luck
      Søren

  • 0 in reply to Soren Steen Christensen
    Prodigy 90 points

    Hi Søren,

    Not really, but we find out something more detailled.  The PLL power was missed somehow, so the MUXMODE was always SafeMode. With the fixed board the appropiate Registers for USB/UART/... are now in MUXMODE0. And another hardware change, so our own hardware now initialize the usb driver (other computer shows it again, on my PC the driver for flashing is already installed). Now I can use the EVMFlashTool and the message "Reset target to proceed" disappears, but after 3 seconds i got a error message with a sentences like "Could not connect to target".

    Tracing Vektor I will look tomorrow, today I compile my own ELF binaries with GNU ARM compiler to start it using Lauterbach and switch a little bit with GPIOs. We copied some code from EBOOT BootloaderMain and the very first functions into a small test application.

    This also works, but we got trouble with I2CInit and UartInit (OUTREG8(&pUartRegs->SYSC, UART_SYSC_RST)). It simple hangs. I don't know...

    One more step today, but no general solution for my problems...

     

    I will test some more tomorrow and will post it here. Maybe you can help me a little bit, if you know something more, what is going on...

     

    Best regards,

      David.

  • 0 in reply to David S.
    Genius 3685 points

    Hi David,

    OK - This is great news - Being able to enumerate and getting the error "Could not connect to target" clearly shows that the ROM-code is booting as expected. Assuming the EVMFlashTool is somehow based on TI CSST (I think it is), you normally get the "Could not connect to target" error in case the small piece of code the download tool downloads (in order to perform the actual download) doesn't manage to setup the external DDR memory interface correctly. Do you use the same DDR memory chip as on the EVM or do you use another (unsupported) chip?

    Looking at the Tracing vector won't do you much good while already getting to this point in the process. With respect to your I2C and UART issues I have no really good ideas. Have you checked that the clocks for the IP blocks are enabled in the PRCM module (TRM chapter 4)?

    Keep up the good work
      Søren