Booting from NAND flash on TMCXEVM6657LE evaluation module

I spoke with a colleague. 

He noted what you saw that
"The datasheet shows a setting for NAND boot, but “nand” does not appear in the generic Keystone Bootloader User Guide".

He asked what your behavior was on the EMIF16 pins and whether they were toggling after reset (showing that the DSP was indeed trying to boot from the NAND).

Would you mind to throw a scope or logic analyzer on the bus and let us know if you see movement at boot?

----------

Also - you note above that you use hex6x.exe to make the hex file, but then you compress it using your in-house tool.  I assume you write the straight binary to the NAND.  I suspect if we see traffic, the next step will be seeing if we have inserted some scramble or corruption to the executable during either Hex6x.exe or in the hex to binary conversion.  Translation is always an area of possible corruption.  Is there a way to cross check the final binary, for instance, I have a hex editor that we could use to cross check the hex file to make sure the binary loads/converts right?

I noticed from the assembly language user's guide that hex6x is not a trivial utility.  What call syntax are you using to take your source file (is it .out) to convert it to binary.  Are you sure you used the right switches for the 'endian' ness?

We don't have the capability to analyze the EMIF16 pins on the eval card.  We can use some of our tools to examine signals on our hardware, though.  I'm not prepared to do that, since I haven't ported the app to that card yet.  I'll do that this afternoon, and we'll try to look at as many of the signals as we can to see what's going on.

I'm feel confident that I got the image correct.  I have cross-checked a number of different ways, and the image always seems to be right.  However, it's only right in the sense that it looks like how I think it should look.  There's no guarantee that what I believe to be "correct" is actually correct.  With that in mind, it's probably worthwhile to go over what I did:

1. I created the ELF executable (the "KITT-car" LED flasher) using Code Composer.  I ran it using the Blackhawk emulator, and I saw the LEDs dance.

2. I converted the ELF executable to hex using this command: hex6x --ti_txt --boot executable.  That created a text file which contains a bootable version of the executable, in TI's boot table format.

1. I verified the image by looking at it in text editor.  The first four bytes are 00 35 82 00, which, when interpreted as little-endian, produce the DWORD 00823500.  According the app's map file, the entry point of the program is 0x823500.  The first DWORD in a TI boot image is the entry point, so this is correct.

2. The next two DWORDs in the boot image are the size and load address of the first section.  Continuing with little-endian interpretation, the size is 0x1440, and the load address is 0x84102c.  The map file says that the .cinit section is at 0x84102c, and it is 0x1440 bytes long.  Again, this is correct.

3. I calculated the address of the next section to be 0x144c, and I located that in the file.  The address and size there corresponded to the address and size of the .text section in the map file.

4. I continued this for all sections.  Everything matched up to a section in the map file, so I assume that this file is correct.

• I ran my text-to-binary utility, and I checked its output using a hex editor.  The sections matched the map file and the hex file exactly.  To further indicate that the sections are correct, I saw my text strings in the .const section of the file (using the ASCII-viewer part of the hex editor).  I am confident that this file matches the hex file.

• I loaded my hex file into NAND flash at location 0.

1. I checked the entire loaded image against the file, byte-by-byte, and they matched.

2. I checked individual blocks visually, and verified that they matched what was in the binary file.

3. I wrote a routine to interpret the boot table, and it correctly listed all the sections and the entry point.

The only real issue I have with my method is that I may have misunderstood how to interpret the TI boot table.  I doubt that, though, since the boot table was built by a TI utility, and it matches my interpretation of the table.

Here are some questions that I have:

Has anyone actually booted the TMDXEVM6657LE from NAND flash?

If so:

What were the switch settings?

What did the image look like?  Was it in boot-table format?  Was it little-endian or big-endian?

Where was the image located?

If not:

Do we know if it even works on this card?

I'll try to get this running on our card, and see if we can look at signals there.  If there's anything else I might try, please let me know.

Thanks,
jw

Hi Jeff,

I might not have all the answers, but i got a NAND boot document that might help you with the boot mode setting and image location. I am attaching the document in this thread, please let me know if this helps.

Thanks,

Arun.

1016.Gauss_nand_boot.docx

Arun,

Thanks for the info.  I saw this document referenced in another forum post (by you, I believe), and it is what I used to determine the format of the boot image.  I've been over that doc a number of times, and I believe that I am following the procedure described there.

I wonder (but doubt) if byte order is an issue.  The only mentions of endianness are in the I²C description, and in bit 0 of the boot configuration word.  Since we're not booting over I²C, I ignored it there.  I've tried setting the hardware switch either way, but it still did not work.  Maybe I should generate a big-endian version of the hex file to see if that makes a difference?

Thanks,

jw

We made some progress today.  We still are not booting from NAND flash, but we see a bunch of good activity on our hradware's EMIF16 bus.  Now it appears to be a software image-format problem.  Here's what we saw:

After a few minor hiccups, we loaded a boot table image into the NAND flash residing on the EMIF16 bus.  Next, we ran an FPGA debugger (configured so that it can monitor EMIF16 signals), and reset the system.  The debugger showed that the DSP read data from the NAND flash, and the data is in the format that is in the flash.  What the DSP does with that data is opaque to us -- that's where we need help now.

I figured that that RBL would read the table, copy the data into target memory, then transfer control to the entry point indicated in the boot table.  Is that the case?

We noticed that there is internal boot loader source code in the MCSDK tools directory.  Is that what is in the DSP?  If so, I ought to be able to look through it to figure out exactly what is expected.

Thanks,
jw 

HI Jeff,

Are you saying thaat the the NAND data has been read by the RBL? After the boot, the RBL, reads from the 1st block and checks if the block is marked good. If it is then it will load the sections based on the memory map. You can verify the section address of your example code and see if they are indeed loaded. Also you can check 0x8FFFFC address in core0 which is the boot magic address to check if it is updated with the start address of your code. Also make sure that it is your reposnsibility to mark the block good or bad. So make sure that you have one of the block containing the image marked good.

I am trying to get an example by this week. I can share with you once I get it.

Thanks,

Arun.

Arun,

All I know is that there is traffic going to and from the NAND flash on the EMIF16 bus.  We see it reading the data that we put in NAND flash block 0.  Where that data actually goes in the DSP, or if the block is good remains to be seen.  Your response raises several questions:

1. Is there some way I can look at the data in DSP RAM and at 0x8FFFFC after the DSP loads data from the NAND flash?  I can't seem to find a combination of options for CCS and the Blackhawk emulator that allows me to do that without resetting the system or loading an image through the emulator.

2. I'm using the eval card's platform library (with some slight modifications to support our larger NAND flash part) to read, write, and erase the NAND flash.  There is a lot of code in there dealing with the NAND device's "spare" area.  I assume that it's managing block integrity.  However, I also see that the nandwriter utility has code to deal with good/bad blocks, so perhaps I need to do it in my code.  If the RBL loads data from the main part of NAND flash, does that imply that it has already checked and accepted the block?

3. In section 2.5.5 of the Keystone Architecture Bootloader User Guide, it says "RBL assumes all the images to big endian mode."  Is that really true for all images, or just those arriving via a serial device?  Does the NAND image need to be big-endian?

4. What is the expected format of the data in the NAND flash?  From the document you sent me, it appears that it should be in "Boot Table" format, as described in section 2.5.3 of the Keystone Architecture Bootloader User Guide.  The source code for the IBL expects it to be in BLOB format, however.  Is is possible that the RBL expects that as well?  What about the boot parameter table; does the RBL need one of those?

Thanks for your responses.  I feel that we're close to solving this one.

jw

Hi Jeff,

I also have been attempting to get the C6657 NAND boot to work.  So far I've been unsuccessfull.  But I did end up finding at one issue in using the EVM platform code to program the boot loader into NAND. 

I placed a hardware watchpoint in the debugger to cover the ECC error address registers were being read, and discovered that these were reporting errors when my boot pages were read from the RBL.

Through trial and error I discovered that the platform code is writing the ECC bytes into different offsets in the spare area than the RBL expects.

In <pdk_C6657_1_1_2_5>\packages\ti\platform\evmc6657l\platform_lib\src\evmc665x_nand.c: writeNandPage there's an offset array that starts with 7, 17, 27, and 37.  It should be 6, 22, 38 and 54:

{  6,  7,  8,  9, 10, 11, 12, 13, 14, 15,

   22, 23, 24, 25, 26, 27, 28, 29, 30, 31,

   38, 39, 40, 41, 42, 43, 44, 45, 46, 47,

   54, 55, 56, 57, 58, 59, 60, 61, 62, 63

};

While I can now see the ECC registers reporting no errors when the pages are read, there's clearly some other problem because the ROM bootloader continues to scan ahead. 

But you could try this out and see if it helps...

-Mike

P.S.

I don't have the setup running at this moment, and it's been a few weeks, but from my notes:

All four ECC syndrome registers are read in rapid succession, starting at about 20b0df00. These are loaded into A4, B5, A3, B1. These are quickly logic 'OR'ed into A4 and masked into B5, *B15[1] and B0. If these are zero there's a branch to 0x20b0e0c6 (ECC syndrome zero), otherwise we land on 0x20b0df48 (ECC syndrome non-zero).

HI Jeff,

Attached is the example for NAND boot. The nandboot.dat file shows the procedure to convert your .out file to boot table and load it into the NAND using your writer. I found one issue is that, the RBL actually resets the NAND flash during the start and starts reading from it, before the NAND was ready. There are two work arounds for this.

1. The NAND responds faster when you reset again after it is powered up. So once you power up the board, send a sunsequent reset after a few msecs delay. This should make the boot process work.

2. You can very well first boot in another mode preferably I2C boot and then jump to NAND boot.

We are working on getting an errata up for this. Will let you know once we get it.

7450.example_release.zip

Thanks,

Arun.

Arun,

I downloaded your example, modified it to produce an output file named simple_ti.bin, then ran.  I then ran the commands that I had been using, which generated a file called simple_mrcy.bin.  I compared the two files using a binary-comparison utility (WinMerge, if it matters).  The files are identical.  Thus, the commands that I use are good.  I've repackaged the zip file to contain the batch files I used to generate the two files, so that you can see what I did.

I also created a small program called boottest.  It simply toggles the GPIO lines 2:0.  We need some way to confirm that the DSP boots, so we put a scope on one of the GPIO lines, run the program, and look for a square wave.  We see that when we load the program into memory using the debugger, both on our card and on the eval card.  When we store the program into NAND flash and reboot, we don't see the GPIO lines toggle.  The DSP did not boot the code from flash.

We see the boot table data come across the EMIF bus, so it appears that the DSP is reading the NAND flash correctly.  I believe that indicates the ECC is not a problem, as was suggested (although I need to look into that more, I suppose).  When I look in L2 SRAM, I don't see the program code at 0x800000, nor do I see the start address loaded into 0x8ffffc.

Did you actually load your program into NAND flash?  If so, did the DSP boot it?  If it did, how could you tell?

If possible, could you try the test program that we use?  It is attached to this message as boottest.zip.  It has the capability to create the binary file using your method or mine.

Thanks,

jw

It looks like the attachments didn't take.  I'll try again.

jw

Here is the other one.

jw

MIke,

This sounds promising.  The initial problem for me is that I'm still using an earlier version of the PDK that doesn't have those tables.  I'll switch to the latest version, and give it a try.  Thanks for the info!

jw

Jeff,

I will try your code today. Yes I tried the code in the EVM. Did you apply a reset after you power up too. As I mentioned, seems like we have bug in the Nand boot that the boot loader reads from the NAND prematurely. So you need to reset it again. If the code works, you should see the boot magic address updated. Also the register A1 should have 11223344 value.

Thanks,

Arun.

Hi Arun,

Sorry to be barging in again on this thread.  Is there any chance that when you run this example, you're actually booting first from I2C?  If not, great!  But I'm worried that you might be because when I step through the ROM boot loader assembly I see ECC errors reported when I use the EVM Platform NAND driver to write the bootloader.  I was forced to tweak the driver before the EMIF hardware started reporting no ECC errors during NAND boot.  I don't see that tweak in your solution, so I'm concerned.  Since the I2C loader is built from the same platform source, the format in that case would automatically agree.

Would you mind double-checking?  Another possibility is I'm using the wrong version of the EVM Platform NAND driver - what version of the C6657 PDK are you using when you write the NAND boot loader?  I'm using pdk_C6657_1_1_2_5.  I've tried earlier versions too.

Thanks!

-Mike

Here's the latest:

I modified the platform library to use the ECC locations that Mike suggested.  NAND reads and writes failed until I erased the flash, so I'm convinced that I got that correct.

I loaded both my and Arun's programs into the first block of NAND.  Neither one ran when booted.

Today's questions:

• Arun:  How are the switches set on your eval card?  The card's manual has two different descriptions of what the switches mean.  I tried both, and neither one worked.
• Arun:  How do you make the reset work using CCS debugger and Blackhawk emulator?  To even get the reset icon to activate, I have to connect to the target.  Then, only the system reset was available.  Is that sufficient?  How do I get the RBL to restart?
• Mike:  How on earth are you seeing ECC errors in the RBL?  Do you have the source code, or are you stepping through assembly code?  I don't know the c6657 assembly language very well (read: not at all), so that is not an option for me.

Thanks, everyone.

jw

Jeff,

My Pins settings are

SW3[1-8] = 11100000

SW5[1-8] = 00011000

If you see the eval board, there 3 white push button in the side. the one in the middle is the resetz trigger. Your steps should be

1. Power on the board.

2. Press the middle push button.

3. Now connect the trarget configuration in CCS and see if the boot succeeds.

Thanks,

Arun.

HI Mike,

I think my board goes through the I2C. But the NAND boot is pure RBL. The code in the I2C doesn't do anything for the NAND. I load the image before hand using a NAND writer I had and then boot in NAND boot. When I loaded the image, I did not encounter any ECC errors.How are you writing into the NAND?

Thanks,

Arun.

Hi Arun,

That's great news that you're not using I2C!  I was using the nandwriter provided in C:\ti\mcsdk_2_01_02_05\tools\writer\nand\evmc6657l\bin.  I used it without modification first; but I could not get it to work.  Eventually I started looking at the NAND access and the ECC error reporting registers during boot.

I assume you're using the nandwriter .out file included with the PDK - if it's part of a particular release could you let me know which one?  Or if it's not, could you attach it?

I'm assuming you are following the standard procedure to get the data into the Nandwriter before it writes to Flash.

-Mike

Hi Mike,

NO I am not using the NAND writer in the MCSDK. I had a writer that was severely hard coded for the flash that we have in the EVM. Unfortunately because of the hard code, we cannot release it. The process to load the image should be fairly standard. Once you get the boot table, just load it into the block whihc you know is good. And mention the block as 1st block. It seems like most of the NAND manufacturers gaurentee block 0 to be good. So you can load it in that block and try out. I can check if using the NAND writer works too or not.

Thanks,

Arun.

I was using my own, home-grown NAND writer utility to load my image.  It uses the platform library to erase, write, and read (for verification) the flash.  It appears to work correctly.

To eliminate any possibility that I had done something wrong there, I tried the nandwrite utility that is in the MCSDK.  It didn't work for two reasons:

• It uses DDR3 to store the file image and the verification data, but the platform DDR and PLL initialization is disabled.
• The only time it accesses the binary data file is to determine its size.  I cannot find any place where it actually reads the data from the file.  I searched for fread, fgets, the file descriptor name ("fp"), and the name of the buffer where it expects to find the binary data to copy into the NAND.

What am I missing?  From what I can see, there's no way that nandwriter could have ever worked.

jw

Hi Jeff,

We use a gel file before starting to initialize the DDR. Having said that are you saying that the platform_lib function has the PLL and DDR initialization disabled? That seems to be still not correct.

Also you will load the dat file to the base of DDR through the CCS.which is defined by a pointer and used in the writer.

Thanks,

Arun.

I look forward to hearing what happens when you erase and reprogram the boot loader using the NandWriter included in the MCSDK, that should help narrow down why we have not yet been successful.  When you try it, please let me know which version it is.

Thanks!

-Mike

Arun,

Would you be willing to give us a snapshot of the raw NAND data in the first few blocks in your EVM?

I've tweaked the Nand Writer to simply do a raw read of the first four blocks of NAND into 0x8000 0000.  Would you mind running this on your EVM?  Then if you could use the Memory Browser... Save Memory... to save 135168 words from 0x80000000.  If you could post that .dat file, that might be the key to figuring out our problem.

I'm assuming that you programmed your application somewhere in the first four blocks - is that true?  I'm also assuming that you're using the EInfoChips TMDXEVM6657L EVM or equivalent.

The data dump contains not just the raw page data but also the raw spare data.  I should be able to use this with a tweaked nandwriter to duplicate your flash exactly on my EVM (at least the first four blocks).  Then I can see if it boots or not.

Then I can work on looking at the differences when I attempt to burn your example program.

-Mike

7318.nandread_evm6657l.zip

Sure. I can get you this by today.

Thanks,

Arun.

Jeff,

Any luck on your side?

Thanks,

Arun.

Nothing new today.  I can't think what to try next; I feel like I've exhausted my options here.

We met with a few TI reps today, and they suggested that we may be able to turn off ECC checking in the RBL, to eliminate the possibility that ECC errors are the problem.  Is that possible?  If so, how can I make it happen?

We also discussed providing us access to the RBL source.  That way, I could see exactly what it's doing, and I may be able to determine why it doesn't work for us.  They said that they'd look into that.  Of course, from my experience with the nandwriter tool, you can see even that might not work for me.

If you have any other suggestions, I'd be willing to try them.

Also - did you get a change to load and boot my test program (boottest.c)?  If so, how did it go?

Thanks,
jw

Hi Mike,

I am attaching the dump you requestion. I am not sure how to really read the format. please check and let me know if this makes sense. I am trying to see how the nand writer is different in writing it.

Thanks,

Arun.

2311.nandboot_arun_dump.dat

This output file makes things even more puzzling to me.  Here's why:

I used a hex editor to dump the contents of simple.bin as bytes.  It looks like this:

00: 00 00 81 00 40 00 00 00 00 00 81 00 28 A2 99 00
10: 68 91 88 00 A8 00 01 01 E8 40 00 01 26 02 08 01
20: 28 08 81 01 E8 40 80 01 26 36 8C 01 26 02 0C 02
30: 20 A1 01 00 00 00 00 00 00 00 00 00 00 00 00 00
40: 00 00 00 00 00 00 00 00 00 00 00 00 01 00 00 00
50: 01 02 81 00 12 00 00 00 02 00 00 00 10 02 81 00
60: 12 34 00 00 00 00 00 00

If we reinterpret the data as little-endian, 32-bit values, the first 0x18 byte locations are: 

Value       Byte index

00810000 -> 03 02 01 00 (entry point)
00000040 -> 07 06 05 04 (section 0 size)
00810000 -> 0b 0a 09 08 (section 0 load address)
0099a228 -> 0f 0e 0d 0c (section 0 data)
00889168 -> 13 12 11 10 ( ... )
010100a8 -> 17 16 15 14 ( ... )

Switching to big-endian produces this:

00008100 -> 00 01 02 03
40000000 -> 04 05 06 07
00008100 -> 08 09 0a 0b
28a29900 -> 0c 0d 0e 0f
68918800 -> 10 11 12 13
a8000101 -> 14 15 16 17

Arun's dump looks like this:

00000081 -> 01 00 03 02
00400000 -> 05 04 07 06
00000081 -> 09 08 0b 0a
a2280099 -> 0d 0c 0f 0e
91680088 -> 11 10 13 12
00a80101 -> 15 14 17 16

This looks like big-endian DWORDs, with the bytes within each word swapped, like so:

00 01 02 03 -> 01 00 03 02

Where did this come from?  Did your hardcoded NAND writer swizzle the bytes before writing to flash, or did the flash dump routine do that?

For kicks, I'm going to modify my home-grown boot loader to change the data to be like that.  I let you know what happens.

Thanks,
jw 

Hi Arun,

After read the problem Jeff said, I found we were probably confused  at the same qusetion.

Is the I2C, EEPROM, big edian or any other thing make the boot fail.

I am doing the UART boot.

Thanks,

Guo

Hi Arun,

It's working!  (At least some of the time).  If I power cycle, connect, then briefly hit the second button, then I can get the program to run.  But if I do a system reset from the debugger or reset enough times eventually I have to power cycle (and hit the second button) for things to work again.  I can do a reset without kicking off the debugger if I don't hold it too long....

I'm assuming this is the reset issue you reported.  Is the reset a physical signal or is it the NAND Rest command sent over the EMIF?  Does this mean we cannot boot directly from NAND with this version of Silicon, or is there some workaround (like selecting a slower PLL speed at startup?)

Is there a particular address in the RBL where I can set a hardware breakpoint to insure a reliable boot, at least for testing?

I will post the utility that takes the block of data and writes it for Jeff tomorrow morning.  The format is simply the first nand page from the first block (2048 bytes), followed immediately by the 64 bytes of spares for that page, followed by the next page, etc.  It's best to view it in memory after right-click loading in the Memory Browser, since I'm not sure of the exact endianness of the TI dump format. 

-Mike

Great news, Mike!  I look forward to receiving your utility tomorrow.  My big concern is trying to undo all the things that I've done to get to this point, but I should be able to figure it out.

Thanks,
jw 

Great news Mike. Please forward the writer to Jeff.

The problem is in that the RBL gives a software reset to the NAND flash and for some reason the NAND takes too much time the first time to come out of reset. The sucessive resets are faster. So the work around is to apply a reset to the DSP by toggling the RESETZ pin.. What happen in this case is the RBL is re-executed, so it sends the reset command to NAND again and this time the response is quick. The system reset or any reset through emulator will not kick in the RBL, so it will not work.

In your custom board, you can setup your host to trigger the PORz pin to power up the DSP and then wait for few msecs and assert the RESETZ pin to restart the RBL.

Please let me know if you have any concerns over the work around. One more thing we have verified this with the NAND that we have in the EVM and as of now this issue seems to be in all micron nand, but i have no data to prove it. So please make sure that the flash you are using in your custom board is indeed working before you concretely set the time delay between the PORz and RESETz.

Thanks,

Arun.

Jeff,

If you have any issues please ping me and I will try to sync up with you to ramp up tomorrow.

Thanks for the patience.

Arun.

Gau,

Sorry for the delay. i am about to get you a UART boot example. I will post in your previous post as soon as i get it working.

Thanks,

Arun.

I've attached the writer that will take Arun's output and "clone" his flash, including spares for the first 4 blocks of NAND on the EVM.

This works ONLY on the TMDXEVM6657L evaluation board from EInfoChips.

Make sure DDR3 is initialized, if necessary run the "Global_Default_Setup" under Scripts Menu... EVMC6657L Init Functions...

Then, load the attached out file but do not run it.

Open a Memory Browser window in the debugger.  Under the save/load dropdown button in that window, select Load Memory.  (You can also get this from the Memory Window context menu, but to get that right-click window you must first put in a valid memory address.  I typically put in the start of DDR3 or 0x80000000).

Browse to Arun's .dat file.  Then click Next. 

Start address is 0x80000000 (start of DDR3 just as the old NAND writer) and the length is 135168 (4 x 128K blocks / 4 byte words).

Click finish.

Then run the program.  If all is successful, you should get something like this (sorry, I did not update the NAND writer version advertized!)

[C66xx_0] NAND Writer Utility Version 01.00.00.01

[C66xx_0]

[C66xx_0] Writing 256 pages (135168 words) from 0x80000000 starting at block 0 page 0...

[C66xx_0] Assuming Pages packed with main data immediately followed by the spare data.

[C66xx_0] First erasing the first 4 blocks...

[C66xx_0]   Erase successful.

[C66xx_0] Now writing pages...

[C66xx_0]   Write complete.

This does not do a readback verify.  If you like, run the reader that I attached originally to pull out the data and do a file compare to confirm it was successful.  Note that it is doing a raw read and write without ECC, so you may see an occasional bit difference that in theory should be corrected assuming the RBL is properly using ECC.

2335.nandwrite_evm6657l.zip

Hi Arun,

While the first few reboots using the second reset button work, eventually the boot stops working.  Also, any boot attempt after a System Reset does not work.  Do you see the same thing?

Here's my procedure:

1. Power cycle the EVM.  Wait a few seconds.

2. Connect via the JTAG Debugger (required to evaluate the boot).

I can see the boot has failed, because the PC is an RBL address (0x20B11B54)

3. Briefly press the second button on the EVM.

The PC jumps to 0x20B00000 (the debugger automatically halts after it detects the reset, apparently).

4. Run from the debugger, then halt after a few seconds.

The PC is at 0x00810024, success!

5. Repeat 3 & 4.

After a few resets, eventually the boot starts failing (the address remains in the RBL after step 4).  After this point, I never see the boot succeed.

-Mike

It looks like the issue could be simply the external reset while the debugger is connected.  As long as I hit the disconnect button in the debugger before pressing the reset button (the middle one on the EVM), then reconnect I do not see this problem.  This also fits with another bit of bad behavior - the debugger loses its connection and must be restarted if I hold the external reset button for more than a second or two.  It's also odd that when I press the reset button briefly the debugger automatically forces the DSP to halt. 

So it's possible that the debugger while connected can sometimes prevent the DSP from resetting properly after an external reset.

Mike,

It is quite possible that the emulation disrupts the reset sequence. I tried few times, but all the time I did not connect the board till after the reset. But i haven't tried consecutive resets.

But in the real world scenario, mostly you will not connect the emulation right?

Thanks,

Arun.

Hi Arun,

Yes of course.  If the only issue is the debugger, then it's not an issue.

Thanks for your help!

-Mike

Hi Arun,

It's a small thing, but in your example, I don't see the utility to produce the "swap 16" version of the .bin file.  Just let me know if that's already available somewhere because it will save me some time.  Also, perhaps I just haven't seen it yet in the documentation, but is the swap 16 a boot format quirk or is that just an artifact of the utilities that produce the .bin file?

Thanks!

-Mike

Mike,

It is just same as byteswapccs except it does 16 bit swaping as opposed to 32 bit. The copy of the swap16 is in attament in post below for UART boot.

http://e2e.ti.com/support/dsp/c6000_multi-core_dsps/f/439/t/235540.aspx

Thanks,

Arun.

Hi Arun,

Thanks again for your help!  One additional thing has come up - I tried to confirm that we could boot on the EVM without the I2C EEPROM connected.  I lifted the EEPROM SDA pin and connected it with a jumper so I can selectively remove the EEPROM. 

If I leave it connected, it successfully boots.  Then if I disconnect the EEPROM and try another reset (not a power cycle) it does not boot.  I've confirmed the BOOTMODE I2C bit is clear - the DEVSTAT register shows 0x0807.  So in theory the boot ROM should not be going to the I2C for the NAND boot parameter table.

I was hoping to do away with the I2C EEPROM since we're very tight on PCB space.  Is the I2C EEPROM required, or is there something I'm missing?

Best Regards,

Mike

Hi Arun

I tried to use the "NAND boot over I2C example" from "mcsdk_2_01_02_06\tools\boot_loader\examples".In the README file of the example wrote "Re-program the boot configuration table refer to tools\boot_loader\ibl\doc\README.txt on how to program the boot configuration table to EEPROM.

I can not found these instructions on how to program the boot configuration table to EEPROM.

Thnks

Ashok