• State
  • Locked Locked
  • Replies 5 replies
  • Subscribers 99 subscribers
  • Views 906 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.

AM335x ROM boot code not getting clocks to run

utelia
Intellectual 290 points

Other Parts Discussed in Thread: AM3352

Hello,

We have a board with AM3352 which boots from SPI Flash. At some point we started noticing the following two issues, but it is difficult to say if it was there all the time because we have been in prototyping phase.

(1) Running programs in emulator (Blackhawk XDS560USB v2) control got more challenging. It took the following sequence to run a program: 

- Power up the board

- Connect emulator (from CCS)

- Disconnect emulator (from CCS)

- Re-connect the emulator again

and only now you could make all the necessary clocks run (e.g. the SPI clock)

and

(2) The SPI-based (2nd phase) bootloader started crashing at WDT1 disable instructions. It turned out to be the case that we are missing the clocks again. 

I have been debugging both failure patterns and it turns out that for some reason, the ROM boot code cannot make the WDT1 setup and PLL etc. configuration work. The processor however runs all the way through the ROM code, which is being indicated by the fact that we do end up running our own SPI based boot code. 

Looking for anything that would be similar to this in E2E, I found a discussion about EMU pins. AM335x TRM states that EMU0/1 pins determine whether the the device goes to WIR (wait in reset) mode or not. There are also bit combinations which, if applied to EMU0&1, make the processor go to undefined state. When emulator is attached, we have 0 and 1 for EMU0 and 1, respectively. This means the processor goes to WIR state which is expected. Errata/Advisory 1.0.36 reads that EMU pins are only latched at falling edge of WARMRST – which is an OUTPUT (and not rising edge of the reset input) . We see these WARMRST falling edges when connecting with with emulator. However, when booting up from SPI Flash, we see no life at WARMRST. EMU0&1 are pulled up and both are logical high when no emulator is attached so if they are latched we know they get the correct values. However, The errata would suggest that a WARMRST falling edge is needed in order to latch correct emu values to processor, and we do not have that.

There ae cases at E2E where someone left EMU01 pins either floating or pulled them down and they have issues starting the processors. Our case is different in that way that we do have the EMU pins configured correctly – we just do not have the WARMRST which might be needed to latch it. Theoretically, we might have a situation that some emulation-time latching for EMU pin values was still there, or some other way not having specifically latched the EMU pins, could now cause the instability we were seeing in the BL. 

Any thoughts?

  • 0
    TI__Guru**** 393215 points
    Hi,

    Can you post the JTAG and reset part of your schematics?
  • 0 in reply to Biser Gatchev-XID
    TI__Guru 63715 points
    Advisory 1.0.36 is trying to describe a case were the EMU terminals were configured to GPIO mode after the system has booted. In this case any device reset causes the warm reset output to be driven low which changes the function of these terminals back to EMU mode. The state of the EMU terminals will be latched five CLK_M_OSC clock cycles - 10 ns later, so it is important that the GPIO function attached to the terminals do not prevent the signals from being pulled high in the period of CLK_M_OSC clock cycles - 10 ns. Otherwise you may not latch the expected value on these inputs.

    In the case of a power on reset, the warm reset will be driven low as a result of this reset. The EMU inputs are latched with the same delay after the warm reset is driven low. So the value of these input will be latched before ROM code is executed.

    Regards,
    Paul
  • 0 in reply to peaves
    Intellectual 290 points

    Thank you for the background of the advisory. I was also uncertain about whether it would be applicable to us. Now if I get you right, you are saying that the correct EMU values are being latched at power-on (reset) before ROM boot code runs even though the (output) WARMRST is not toggling at any time during the process? This would be logical.

    However, this does not solve out problem. I am investigating if I can post the JTAG and reset parts of our design. (Briefly: we have pull-ups for the EMU pins).

    Meanwhile: what else could cause the ROM boot code not to set the clocks? With source code not available, I can see it run in the boot ROM area but figuring out whether it does the same things in fail vs succes case is going to be tough. Can you say if there is any branching in the code, or any other reason which might cause this? 

  • 0 in reply to Biser Gatchev-XID
    Intellectual 290 points
    Is there a way of sending them to you privately?
  • 0 in reply to utelia
    TI__Guru*** 125430 points

    Do you have JTAG available?  I have written a couple scripts for scraping important values from memory and doing some interrogation.  It might help us understand what's happening.  Does it sometimes work and sometimes fail?  If that's the case, it would be great to get a snippet from a good case and bad case for comparison.

    Here's one of the scripts:

    http://processors.wiki.ti.com/index.php/AM335x_board_bringup_tips#Analyzing_Boot_Issues_with_CCS_and_JTAG

    Since it's clock-related you should also run this one:

    http://processors.wiki.ti.com/index.php/AM335x_Clock_Tree_Tool#Importing_Data_from_Actual_Hardware

    You can attach the resulting output files on the forum.