OMAP3503 USB boot issue

Hi Vini,

To me this mostly sounds like that one of the SYS_BOOT pins isn't soldered correctly on the given board => The ROM-code won't try USB-booting. In case you are using external resistors for selecting SYS_BOOT pin values (HIGH/LOW) have you double checked that all are correctly mounted and that the PicknPlace machine didn't drop any of them on that single board?

You can readout the value of the ROM-code Tracing vector at addresses: 0x4020 FFB0 and 0x4020 FFB4 - More information to be found in the OMAP3 TRM (spruf98g.pdf) chapters 25.4.2.2 and 25.4.9...

You can read the value that the OMAP sampled for SYSBOOT during Power on Reset at address 0x4800 22F0 - Please consult Table 7-103 CONTROL_STATUS of the OMAP3 TRM for further onfo on this...

Best regards - Good luck - I hope this helps you forward
  Søren

I think you're looking at the wrong USB.  The USB boot mode is over the OTG, not the host controller.

Hi Brad,

This kind of thought as well hit my mind, but how should they even try to connect the Host port to the PC for connectiong to the EVMflashing tool? To me a setup like this doesn't make any kind of sense :-).

I therefore assumed that they had connected the USB3322C to the OMAP OTG interface - Should't the OMAP be able to do peripheral boot through this as well (as through TPS65950) given it's properly powered at power up? Last but not least, the way I read the post is, that the setup is only failing on one (out of several) boards.

Hopefully Vini will be able to clarify?
  Søren

Hi Soren,

You are right. We are using USB3322 on OMAP OTG port and this port is used as a device only in our board. As far as the assembly for the SYS_BOOT pins is concerned, I verified this by successfully toggling the SYS_BOOT pins as GPOs after booting through serial port. I am going to check the status for CONTROL_STATUS and the ROM tracing vector and will update you guys shortly.

Vini

Hi Soren,

I checked the CONTROL_STATUS register . It reads as 0x0000032F and this shows that OMAP is detecting the SYS_BOOT[5:0] = 0x101111 sequence correctly. But the tracing vector shows that BOOT ROM code is not running whenever I try to boot from USB.

The tracing vector on non-working board reads as 0x4020FFB0 = 0x0000003B; 0x4020FFB4 = 0x001E0004 when tried to boot from USB which shows that boot ROM code does not get executed.

When tried the same on working board, tracing vector reads as 0x4020FFB0 = 0x0044F04F; 0x4020FFB4 = 0x00000000 which shows that boot ROM code gets executed and peripheral boot is happening from USB.

I compared the power on sequence and clock stablization times for both the boards and these are same except the reset out from OMAP i.e. SYS_nRESWARM that is released after ~605us w.r.t. to SYS_nRESPWRON on non-working board as comapred to ~480us on working board but this should not be an issue as this is not used for ULPI TXCVR or any other device in our board.

What can be the possible reason for boot ROM code not getting executed for USB boot?

Vini

Is sys_32k present and stable?

Hi Brad,

Yes, sys_32k is present and stable.

sys_32k starts as soon as VDDS is stable in our board and this stablizes ~200ms before nSYS_RESPWRON is released.

Vini

Hi Vini,

I actually think the SYS_nRESWARM might be an important point in understanding your problem. Main problem is that the ROM code doesn't think it's doing a cold reset (bit 2 in the Tracing Vector not being set). Since a cold reset isn't detected it won't try to do peripheral booting (but only memory booting from NAND where it finds nothing after checking the first 4 blocks). I do however unfortunately not have any brilliant idea why/how this can be the case. Hopefully somebody from TI can comment further on this :-)

Why you are able to do peripheral booting over UART is as well kind of very strange to me... :-)

I'm unfortunately current out of ideas - In order to help others please report back when you find the root cause of the problem - Meanwhile - Good luck
  Søren

Hi Soren,

While going through errata for OMAP35x, I found there has been a similar issue for OMAP35x Rev 2.0 silicon. Though Rev for my OMAP chip is 3.1, I was just wondering if this issue is still carried on in OMAP silicon :).

But as per errata, applying a second power on reset on nSYS_RESPWRON should solve the issue but unfortunately this didn't work for my case.  As per errata, this workaround depends upon the hardware capability of board. Can anyone from TI clarify what does this actually mean?

Vini

Hi Vini,

I guess you are referring to: "Advisory 2.0.1.105 - ROM Code: Second Power-On Reset Required for USB Boot" in the errata document?

I have two arguments why you are not hitting this:
  1) You are using a newer silicon revision. Normally you can feel pretty sure that a bug listed in the errata is actually fixed if it's stated that it's fixed.
  2) The Tracing vector of your failing device tells, that it even doesn't try to do peripheral booting...

Unfortunately I think this you are heading a wrong path
  Søren

Hi All,

After a long time, same issue is haunting me again. Just to summarize the conversation till now:

1. We designed a board with OMAP3503 CBC package and USB3322C ULPI PHY is interfaced with OMAP OTG interface and OTG used in device only mode.

2. Out of the first two boards that we assembled, we were not able to boot from USB in one board. We were able to boot through UART. The tracing vector on non-working board showed that OMAP is not even trying peripheral boot. We toggled all the sysboot pins as GPIOs successfully to confirm OMAP assembly. Also, after booting through UART, we were able to work with USB client normally without any issue and this confirmed that there was no assembly issue.

Now coming to the latest updates, in the board referred in above conversation, after trying all possibilities, we manually wired a USB3320 chip with everythnig else same. And to our surprise, USB boot worked (With all those wires hanging :) ). Now interesting point is that all the electrical specs are exactly same for USB3322C (0.4mm BGA package) and USB3320 (QFN package). So, I didn't get any clue why it worked with USB3320.

Anyway, we were having only two assembled boards and success rate was 50-50. So, we went for Rev B of board without any change in this section hoping that if it is working with USB3320, it should work with USB3322C also. This time we assembled four boards and out of these four boards, USB boot is working properly in three boards . But USB boot is not working in the fourth board.(75-25 success rate :) ).

And again USB is working without any issue after booting through UART in this fourth board. The only new observation here is that the very first time when we tried USB boot in this board, it didn't work with serial UART cable connected to PC. After removing serial cable, USB boot worked. Again after connecting this cable, USB boot didn't work. So, we thought this to be some board dependent issue and left it as it is. But when I tried to debug this issue the very next day, the board is not booting from USB at all (w/ or w/o serial cable). It is behaving in exactly same way as the one Rev A board was behaving. And now I am not able to decide what is the actual issue.

Can anyone from TI tell whether there is some issue with USB3322C and OMAP35x combination while using this ULPI PHY with OMAP OTG port?

Vini

Can you check CONTROL_STATUS and the tracing vector again?

Do you see any activity  to the USB3322C when doing the USB boot?  Fundamentally it would be go to know whether the issue is with getting your OMAP to attempt USB boot, or if the issue is with a failed USB boot, i.e. it tried but was unsuccessful.

All the strange behavior with having UART cables connected or not connected makes me wonder if you have some sort of ground issue.  Perhaps another data point might be to see if there's any difference when connecting the board via USB to a laptop that is plugged into the wall vs a laptop running on battery.

I don't think there's a problem with using either of these devices for USB boot.  I think it's a board issue.

Hi Brad,

I checked the tracing vectors for different scenarios and here are the results:

When the NAND Flash is empty and board is powered:

Tracing Vector is :

@0x4020FFB0 = 0x0000003B

@0x4020FFB4 = 0x001E0004

@0x4020FFB8 = 0x00000002

@0x4020FFB0 = 0x0007307F

@0x4020FFB0 = 0x001E0044

And CONTROL_STATUS is :

@0x480022F0 = 0x0000032F

Here OMAP is trying to boot as per the sequence configured by sys_boot pins. This is as excepted.

When the NAND Flash is empty and USB booting is tried from EVMFlash application :

Tracing Vector is :

@0x4020FFB0 = 0x0000001B / 0x0000001B / 0x00000003

@0x4020FFB4 = 0x00060004 / 0x00000004 / 0x00000000

(The value for above two addresses was different at different times)

@0x4020FFB8 = 0x00000002

@0x4020FFB0 = 0x0007307F

@0x4020FFB0 = 0x001E0044

And CONTROL_STATUS is :

@0x480022F0 = 0x0000032F

Here it seems that OMAP is not trying peripheral boot once EVMFlash application is used. This is what is confusing here.

When the NAND Flash is empty and UART booting is tried from EVMFlash application :

Tracing Vector is :

@0x4020FFB0 = 0x0047F04F

@0x4020FFB4 = 0x00000000

@0x4020FFB8 = 0x00000001

@0x4020FFB0 = 0x00000000

@0x4020FFB0 = 0x00000000

And CONTROL_STATUS is :

@0x480022F0 = 0x0000032F

Here OMAP is booting from UART after trying USB boot and it is as expected as per boot sequence configured through sys_boot pins.

Once eboot is written to NAND Flash using UART and board is powered normally :

Tracing Vector is :

@0x4020FFB0 = 0x0047385F

@0x4020FFB4 = 0x00020044

@0x4020FFB8 = 0x00000001

@0x4020FFB0 = 0x00000000

@0x4020FFB0 = 0x00000000

And CONTROL_STATUS is :

@0x480022F0 = 0x0000032F

Here OMAP is booting from NAND after trying booting from USB, UART and MMC1 and it is as expected as per boot sequence configured through sys_boot pins.

Conclusion  :

Only the boot from USB fails and the boot sequence from OMAP as per the tracing vector is unexpected in this case. And as previously USB interface is working fine after booting through UART. 

Do you get any clue from this data? This is exactly what was happening in one of my Rev A boards and USB boot in the same board worked when I wired USB3320C manually. And thats why I had a doubt regarding OMAP35x and USB3322C combination.

Vini

One thing to check is to see if the USB PHY is in a valid state when the ROM attempts to access it.  You need to ensure that the power supplies have ramped properly and check to see if the PHY requires a hardware reset (and maybe some setup time after that).  Since you can get the USB working after a UART boot, you may not be giving the USB PHY enough time after power up to be ready for activity. 

Another clue might be to try to run the ROM code from Code Composer if you have that access.  Once it has successfully booted, perform a CPU reset from CCS (it should start at 0x14000).  If it can boot successfully from USB, then you probably have some sort of initialization issue as mentioned above.

Also, for the tracing vectors, you really want to look at 0x4020ffBC and 0x4020FFC0, as these reflect the tracing vectors after a cold reset.  I think that is what you show but you have typos in your addresses.

Regards,

James

Hi James,

You are correct. The last two locations are actually 0x4020FFBC and 0x4020FFC0 in my previous post for all the cases. Sorry for the typo. 

I am a little bit confused here and need some clarification for below items:

1. What is the difference b/w two tracing vectors i.e. current tracing vectors ( at 0x4020FFB0 and 0x4020FFB4) and the cold reset run tracing vectors (at 0x4020BC and 0x4020FFC0)? As per my observation, cold reset run vectors are 0x0 whenever there is successful booting as mentioned in my previous post. What does it mean?
2. What are the dead loops and how can OMAP BOOT ROM code can end in a dead loop? And what will happen once OMAP end in a dead loop? Will it come out of it on next power ON or will it be stuck there only always?
3. What are the possibilities of OMAP BOOT ROM getting corrupted and what may be the cause for ROM getting corrupted?

 Now, I did try to set PC = 0x14000 through CCS but was not able to get any useful information. Once I "Run" the code after setting the PC to 0x14000, CCS shows "running" and "in reset" alternately. And once I "Halt" to see the value of PC and run again it shows "running" continuously. On next time at "Halt", PC is at 0x1408C which is a dead loop saying "Data abort exception default handler". What does it mean?

I understand that when using JTAG and CCS and setting PC to 0x14000, the program will execute from BOOT ROM but this execution should be very slow than the normal power ON execution? Am I correct? Will UART/USB booting work while excuting code from CCS? For my board, UART boot is working properly on normal Power ON but I am not able to get it working from CCS after setting PC to 0x14000. The EVMFlash application keeps on waiting for the device to reset and does not detect the code running from BOOT ROM. I don't know how to debug USB booting issue through CCS as even UART is not working in this case. Does OMAP go to some specific debug mode when JTAG is connected? How is it different running BOOT ROM code from CCS than this code running normally after power ON?

I simply wanted to know where the BOOT ROM ends when I try USB booting. If I connect JTAG after powering ON it again resets the OMAP and I get PC = 0x0. And when I try to run ROM code from CCS, it doesn't seem to work with UART itself. Is there any other way to do it?

Vini

Are you able to make this work correctly on the EVM?  Are you using the same mDDR/NAND as the EVM?  If not, then some changes to EVM Flash would be necessary to adjust for your timings.

Vini said:

• What is the difference b/w two tracing vectors i.e. current tracing vectors ( at 0x4020FFB0 and 0x4020FFB4) and the cold reset run tracing vectors (at 0x4020BC and 0x4020FFC0)? As per my observation, cold reset run vectors are 0x0 whenever there is successful booting as mentioned in my previous post. What does it mean?
• What are the dead loops and how can OMAP BOOT ROM code can end in a dead loop? And what will happen once OMAP end in a dead loop? Will it come out of it on next power ON or will it be stuck there only always?
• What are the possibilities of OMAP BOOT ROM getting corrupted and what may be the cause for ROM getting corrupted?

There is a watchdog active at boot which will eventually timeout and cause the device to reboot.  So you'll have "cold boot" the first time and then if that fails it will keep on rebooting over and over.  The 2 different trace vectors allow you to see the first boot and the most recent reboot.

The dead loops are intended for error conditions.  If an error condition is hit then the CPU will just spin at one of the dead loops.

There's no possibility of the ROM being corrupted.  It is manufactured into the device and cannot be altered.

Vini said:

I understand that when using JTAG and CCS and setting PC to 0x14000, the program will execute from BOOT ROM but this execution should be very slow than the normal power ON execution? Am I correct? Will UART/USB booting work while excuting code from CCS? For my board, UART boot is working properly on normal Power ON but I am not able to get it working from CCS after setting PC to 0x14000.

If you're single-stepping it will be very slow but otherwise the code runs at the same speed regardless of having the emulator connected.  Be careful with gel files so you're not changing a bunch of registers...

Hi Brad,

Thanks for your reply.

We are using two EVMs - Mistral OMAP3530EVM Rev D and Mistral OMAP3530EVM Rev G. And we are not facing any issue on the EVM.

The POP memory used in Mistral EVM Rev D is Micron MT29C2G24MAKLAJG-6 IT ES (2Gbit NAND and 1Gbit LPDDR). EVMFlash3530_v1.2 is used for this EVM.

The POP memory used in Mistral EVM Rev G is Micron MT29C2G48MAKLCJI-6 IT (2Gbit NAND and 2Gbit LPDDR). EVMFlash3530_v2.0 is used for this EVM.

POP memory used in our board is MT29C2G24MAKLACG-6 IT (2Gbit NAND and 1Gbit LPDDR). We are using EVMFlash3530_v1.2.

But I feel it should not be a memory chip issue due to following observations:

1. It is not the case where EVMFlash tool gives some error while writing to NAND. PC is not able to detect the OMAP itself (as a device) when trying to boot through USB. And EVMFlash tool keeps waiting for board to be resetted.
2. This is happening only in few boards (in 2 out of 7 working boards) and not in all the boards.
3. UART boot is successful in all the boards (including the problematic board) with same memory chip.

I had tried to capture the communication on ULPI bus between OMAP and PHY initially with my Rev A board and suspected that the data written to ULPI function control register by OMAP was 0x4D which means that opmode(1:0) = 0b01 which results in ULPI PHY going to non-driving mode and thus no pull up on the D+ line and no device detection by PC. On the working board, 0x45 was written to this register which means opmode(1:0) = 0b00 and results in normal USB operation.

I dont know in which case OMAP should write this to ULPI PHY. Can anyone throw some light here if this gives some information? But once I wired USB3320 on problematic board, it started working.

Can someone telI the expected data sequence on ULPI bus that OMAP BOOT ROM should send to ULPI PHY during PHY initialization phase during USB booting. I don't have any ULPI bus analyzer but I can again give a try to capturing this data through my MSO if I have some reference. 

Vini

I've attached a USB trace of the traffic during a USB boot.  This particular trace is not from a successful USB boot, it is just showing what the ROM does initially.  You can use viewer software from Lecroy to view it. 

It still seems like you have something marginal on the non-working boards.  Have you verified power sequencing and resets to the PHY?  Maybe looking at ULPI data signals will give a clue, maybe there are possible noise issues on these signals.

Regards,

James

Hi James,

Thanks for sharing the USB trace data. It will take some time for me to verify this.

Meanwhile, I was just going through the errata (TI document # sprz278f) and came across the Advisory 3.1.1.195 "HSUSB Interoperability Issue With SMSC USB3320 PHY". As per this errata there is some compatibility issue b/w OMAP and USB3320 during suspend sequence. Though this issue is related to OMAP host port and not the OTG port which is used for USB booting, but can this behaviour of SMSC PHY can affect USB booting

PS: USB3322 (what I am using) uses same die as USB3320 as per SMSC.

Regards,

Vini