Uart boot mode stops after 1 c character

Lance,
Do you observe this only on Custom board?
Thank you.

Hi Lance,

We can connect the JTAG emulator to the K2 and connection works, but we cannot connect to any of the cores (ARM or DSP).

You mean to say that the "test connection" get passed when the emulator is connected.

To connect to the target cores such as DSP, you have to provide the gel file in the target configuration file. And also, make sure you have set it in "DSP NO-BOOT" mode. What is the name of the emulator selected and used.

Send us the complete logs and the screenshot of both emulator test connection and "ontarget connect" with gel file.


Regards,
Shankari.

Yes, this is only on our custom board. The eval board sends continuous 'C' characters and the emulator can connect to the cores on the eval board during that time.

Shankari,

Yes, the emulator "Test Connection" function passes and then the list of cores is presented. But it fails when trying to connect to any of the cores. I do not mean to say that it fails when I try to actually do anything with core, it simply does not connect. It gives the following error message:

"Error connecting to the target:
(Error -1321 @ 0x11B64)
Device failed to enter debug/halt mode because security settings prevent debug. Power-cycle the board. If error persists, confirm configuration and/or try more reliable JTAG settings (e.g. lower TCLK).
(Emulation package 5.1.232.0)"

I am using a Spectrum Digital XDS220 emulator. I also slowed the JTAG clock from 10MHz to 1MHz. I have confirmed that the "System Reset" via the emulator from CCS5 causes a reset because the K2 issues another 'C' when I do so.

I run the tests identically on both the our custom board and the EVMK2H eval board, including using the same emulator (we removed the mezzanine emulator and connected the XDS220). I do this to verify exactly how I should expect the board to behave. On the eval board, the 'C's come out continuously and, during that time, the emulator can connect to the ARM core (which, of course, stops the 'C's).

I am not using any GEL files at this point. Our plan is to use UART boot mode to load u-boot and we have prototyped the process on the eval board. The emulator is only there for contingency and debug purposes so we do not use a GEL file to perform any initialization.

Thanks,

Lance

Hi Lance,

I have few questions before look at the UART boot issue. What is the part number on the custom board ? Are you using sure you are using a GP(non-secure) K2H part on the board. What is the reference clock on the board and have you checked that there is no noise on the clock lines. Is there any test point on your board where you can check if the SOC PLL is set up correctly and can be observed correctly when the character stops printing. I suspect that you may have some issue with your emulation pin hook up as you are not even able to connect to the device in no-boot mode but we will need to loop in a few hardware folks to confirm your settings.

I will include some hardware experts to provide more inputs but at the moment this doesn`t appear to be a problem with the Rom bootloader from the symptoms.

Regards,
Rahul

Hi Lance,

Is it possible to check whether the SOC has stopped operating by probing the SYSCLKOUT pin? JTAG connectivity usually only requires power, clock and the release from reset to operate. In addition, is it possible to try booting your board in 'noboot' mode to see if the same problem occurs? This would help to determine if a setting in the bootrom is causing the problem.

Regards,

Bill

Rahul,

Thanks for the response. First, let me answer your questions then update you an what we have seen.

The part number is 66AK2H06. This is a non-secure part. We are using a SYSCLK and ARMCLK of 122.88MHz. We have looked at various clocks including a test point for SYSCLKOUT and they all good and as a expected.

We changed some of the reset sequence timing (but the notes are fuzzy on exactly what), and we are much further along. First, the 'C's not come out every 5 seconds for about a minute just as they do on the eval board. But the xmodem transfer stops early. It has downloaded as much as about 25% of the u-boot image (about 100K). When it does stop, the power on the board (which has little else running) drops noticeably (a little less than 10%). This is a new development and I am still collecting information, but I do have a question:

What happens if there is an error in transfer -- say, a corrupted character -- during the UART boot? Does the K2 immediately stop and go to sleep? Are there retries? What are the limits?

The second development is that we can now connect to the cores with the emulator. In fact, we have been able to download u-boot and get it running properly out if DDR memory. But this is somewhat inconsistent. When it works, it runs completely and continues to run, even running memory diagnostics without fail.

When it fails, it always fails the same way (to the extent we can observe it). It runs fine while executing our of K2-resident RAM, but fails to run when it relocates itself to DDR. When stopped with the emulator, it is in the data abort or pre-fetch abort vectors. Using breakpoints, it appears to hit the pre-fetch abort first. In fact, we have stepped through the code and found that it aborts when stepping the "BX lr" which is the instruction that first takes it to DDR code. But looking at that target code in DDR, it is exactly what is expected. That is, DDR itself -- at least in the areas we check -- appears to be okay.

We are still looking at things and trying to find a cause. If any of the symptoms ring a bell, let us know.

Thanks,

Lance

Bill,

Thanks for the reply. We a test point on SYSCLOCK out and it appears to be solid (see my response to Rahul). We have not been able to try no-boot mode yet (but that is on our list).

However, we have verified with the EVM board that the emulator can take control of the processor during the time UART-boot is actually active. As I told Rahul, the emulator now connects to the processor. We suspect that it could not do so before because the boot loader was stopping after 1 'C'. It now continuously prints them until it times out.

Thanks,

Lance

Hello Lance,

When it does stop, the power on the board (which has little else running) drops noticeably (a little less than 10%). 

What is the level of core voltage when it stops the transfer ? Is the level within the limits given in the recommended rating ?

Did you find the cause for this voltage drop on your board ?

Regards,

Senthil

Senthil,

The voltage (CVDD) remains unchanged at about 1.0 volts.

I stumbled onto a clue and an apparent solution. Remember from an earlier post that we had the periodic 'C's coming out at this point (the single 'C' problem is gone). We are using TeraTerm to perform the Xmodem download (if you have a better solution, let me know). I had been using Xmodem 1K, which is what we do on the EVMK2H board. But I accidentally configured TeraTerm to use Xmodem Checksum and now it works reliably.

TeraTerm actually reports that it is using Xmodem CRC, and it also works if I select that mode. I suspect that it is actually using the CRC variant and that it automatically switches to it because it sees the 'C'.  The only difference between CRC and 1K variants is the packet size -- 128 bytes versus 1024 bytes, respectively.

Xmodem 1K works perfectly with the EVM board, but has never gotten past about 100K on our board. So, while I have a suitable work-around, I do not know why it was failing and what other implications the symptom has.

I believe the drop in power is simply the boot core (ARM in this case) going to sleep after a failed download. The same drop in power occurs when I let the loader time out without sending a download.

Thanks,

Lance

Hello Lance,

Sorry for the late response.

Are you still working on this issue ?

TeraTerm actually reports that it is using Xmodem CRC, and it also works if I select that mode. I suspect that it is actually using the CRC variant and that it automatically switches to it because it sees the 'C'. 

I am not very clear about this statement. I think TeraTerm is switching the mode from Xmodem CRC to Xmodem 1K when it sees the "C". Is my understanding correct ?

Xmodem 1K works perfectly with the EVM board, but has never gotten past about 100K on our board. So, while I have a suitable work-around, I do not know why it was failing and what other implications the symptom has.

May i know what is the workaround you are having to overcome this issue ?

Since you are not having any issue on Xmodem 1K with the EVM, we could not be able to reproduce your issue from our side. So please describe your issue in more detail to help you out.

Regards,

Senthil

Hi Lance,
Thank you for the update.