OMAP3503 Reset Problems

This is a tough one, my first thought would be to verify if this is some instability in the device or if it is a consistent failure which brings a couple of questions to mind:

1. Is this happening on multiple new boards in the same fashion or just one particular board?
2. Since you can work with the device over JTAG can you load and execute some simple piece of code stably?

Brad Braun said:

If I force the registers on our board to the same values as the EVM (manually set them through JTAG), I can single step through the code to the point where the ROM code loads the CONTROL_STATUS register from 0x480022f0 (SYSBOOT pins).  For both the EVM and our board, this is read as 0x335.

When you say you force the registers to be like the EVM which registers are you having to change (program counter and ...)?

This makes it sound like the RBL runs correctly if properly branched to and backs up the proper state of the SYSBOOT pins, and it seems things are not entirely out of whack since it looks like your device is at least trying to run the RBL at boot since 0x17562 is within the code/data space for the RBL. If this is the case and there is some failure before the RBL the main issues I would look for would be general stability (voltages, clocks, etc as you have checked), or some reserved pin being put in an incorrect state. Given the symptoms my best guess would be that you have some pin connected incorrectly so it may be worth verifying the power and ground pins against the datasheet and EVM schematic, as well as the sys pins.

Thanks for your thoughts on this Bernie.

" 1. Is this happening on multiple new boards in the same fashion or just one particular board?"
Happens on all the boards that we've tried.

2. Since you can work with the device over JTAG can you load and execute some simple piece of code stably?
I had stepped through ROM code without issue and had measured the clock, power and reset signals.  That said, you make a good point.  I inserted a simple dead loop in SRAM 4020 0000 and let the code run.  Sure enough, I ended up back at the 0x17568 address.  I tried the same thing on the TI EVM and it can loop at the location indefinitely. 

Further, when I scope the nRESWARM output while the unit is running, I see a periodic reset.  I suspect a HW problem at this point (as you were suggesting).  Out of curiosity, if the ROM code cannot boot successfully from UART or NAND (the two sources configured via the SYSBOOT pins), does it just end up in a deadloop (this is what I expect)?  It doesn't trigger the resets that I'm seeing, does it?  I'm going to erase the flash on the EVM board and see what happens on that platform.

Brad

A couple of updates:

1. Re. Test Code in 0x40200000 - the dead loop that I referenced in my previous email.  The code runs there until the Watchdog reset fires (approximately 10 Seconds).
2. To ensure the comparison to the EVM was valid, I checked the EMU0/1 switches on the processor board and adjusted them to match my platform.  In that case, the behavior in the dead-loop is the same, watchdog reset after approx. 10 seconds).
3. Out of warm reset, the behavior of my target board is different than the EVM regardless of the settings on the EMU pins.  Our board shows a periodic reset every 12.25 mS while the EVM does not.  The reset reason PRM_RSTST is 0x02 (GLOBAL_SW_RST).  I know that I'm not issuing the SW reset because the process never seems to get beyond the ROM code execution.

Any thoughts?

Brad

Do you have the same silicon revision on both your EVM and your hardware?

Brad has a good point about checking silicon revisions, that is one possible difference we can look into from the errata.

Do you have any control over the boot pins on your custom board? If possible I would be interested to see if it reacts differently with a different sys_boot pin setting, in particular one that starts with UART so you could easily see the device trying to boot over UART and verify if that mode is stable or not. The suspicion here being that something in your NAND booting image is throwing the ROM boot loader off, though if the flash is clear already, I would expect the same operation on the EVM. The ROM boot loader documentation in the TRM does mention the ability to peform a software reset, but in normal good operating conditions this would be done by user code and not the RBL, unless the RBL detected some bad condition (i.e. before it goes into one of the dead loops from section 26.4.2.1)

The EVM board is an OMAP3530 (ES 2.1).  Our board is an OMAP3503 (ES 3.1).

I just saw Bernie's post come in also.  We do have the ability to modify the SYSBOOT pins if we need to.

I the current configuration, the platform is designed to boot first from UART3 and then from NAND (both the EVM and my platform are the same in this regard).  In the process of trying to rule things out, I did the following:

1. I am using a program called EVMFlash.  It monitors for the UART3 message from the OMAP on boot, sends the "Continue peripheral booting" message and then sends out a boot program that is stored in SRAM for execution.
2. I modified the program that is loaded into SRAM so that all that it does is branch back to 40200000 (basically just to get a really basic scenario operational).
3. Captured the serial transfer from both platforms out of reset.  Both platform send a 58 byte message on POR.
4. The EVMFlash program sends "continue perhipheral booting", a count (4 bytes) and the branch back to 40200000 instruction.
5. On the EVM platform, the OMAP responds with - A1 20 00 00 00 00 02 00 00 00 less than 100mS later and then - A1 20 00 00 00 00 02 00 03 00 another 600 mS after that.  If I have JTAG connected, I can halt the processor at this point and validate that the code is spinning at 40200000.
6. On my platform, I get no response ot of the OMAP after it receives the data from EVMFlash.

I re-scoped the reset signals and verified that there is a 300mS delay after POR before the reset signal begins to toggle every 12.25 mS, so it looks like the processor is correctly waiting for a response and then timing out.

With all that said, my current suspicion is that there is some glitch on the board with the receive path on the UART.  I'm off to work with the HW guys a bit to check through this cct and I'll let you know how it turns out.

Thanks for all of your input on this.

Brad

There was a buffer for the receive path on UART3 that was not properly enabled out of reset.  With an appropriate modification in place, I can now download a small file to SRAM and execute it.  I no longer get the continual reset because the ROM code is able to process the boot source.

Thanks again for you input. 

Hi Brad,

I am having a similar problem, can you tell me what the modification was that fixed this for you?

Thanks

Hi Steve,

In the case that I was investigating, a buffer was not enabled properly in the hardware.  The boot character was being sent out correctly, but the processor did not see the response from the EVM Flash application on the PC side.  Once this was addressed, everything worked as expected.

Brad