using linker to workaround bootloader using L1D

MattLipsey said:

I broke in with the emulator with no gel file loaded, and the bootcfg register was as expected but the bootcmplt register had a nonzero value in the error field.  According to the dm6435 datasheet, I should check SPRAAG0 for the error codes.  I couldn't find any specific error codes there, only a mention that errors would be written.

I am not sure why these errors were never added to the SPRAAG0 document, however you can find a listing of the error codes at https://community.ti.com/forums/p/1018/3621.aspx#3621 (different device but same codes), however if your application is mapped so that it overwrites the RBL as it is executing you could end up with anything in the BOOTCMPLT register.

MattLipsey said:

Edit: I tried this and it didn't work.  Apparently there are 2 words worth of initialized data at the beginning of the heap.  I have 70k of heap in L1D, so I can't meet the 20k requirement no matter where I place my heap.  Is there a workaround?  I vaguely seem to remember something about run time initialization of variables as opposed to load time... is this my answer, and is there a way to limit it on a section by section basis?

I am not sure if you could do this with the heap based on your findings but it may be worth trying to set a seperate run and load address for the 20k heap section in a custom linker command file as discussed in section 7.9 of SPRU186, on the other hand you should be able to perform run time initialization on static data (like a global array), so if you made a seperate memory section over the problematic 20k of L1D and allocated some static data there that was set to be run time initialized than you should be able to get past this. Alternatively if you have some large data structures that you happen to allocate out of heap now that you could allocate manually (i.e. make a pointer and put the data there) into the 20k space instead of from the heap than that could work as well, though this is roughly the same as the static data method only you would get a pointer instead of an array and you would be responsible for maintaining the allocated sections manually (may not be a problem if you have a just few large arrays to put there).

Going to the linked page, I see that I am getting a CRC error.  Any suggestions for chasing this one down?  Here are my steps so far:

1) I have a simple application that blinks 2 LEDS on my hardware.  I burn it to flash using the hexAIS & flashburn for EMIFA fastboot.  It boots and functions as expected.

2) I have my actual application that works fine through the emulator.  I burn it to flash the same way and it does not work.

3) I modified my application to contain a simple forever loop waiting for a volatile variable to be changed.  I break into it with the emulator with CCS with no gel file loaded, load symbols only, and get junk.  The bootcfg register contains the correct values, the bootcomplt register contains the error code for a crc error.  ( At this point I added the same loop to my blinky app, and was able to break in as expected.)

4) Thinking that having data in the lower 20k of L1D was causing my issues, I temporarily changed my heap size so that nothing would be placed in the lower 20k of L1D.  Same error.

I checked my linker options and I have run-time autoinit enabled.  I was under the impression that this meant the bootloader would finish completely, then branch to c_int00 which would then perform initialization of these variables.  Meaning it shouldn't matter that data is allocated to L1D because the bootloader would be finished before it hit the initialization routine.  Am I incorrect in my understanding?

I will continue trying to track this down.  Is there any way to get more info about the checksum error?  I have the write verify box checked in flash burn, is that worth anything?

Thanks for the insight.

After some more digging, I am even more perplexed.  Here is what I have found:

The AIS script is not behaving like I would expect.  I have gotten down to parsing the actual commands from flash, referencing them to SRPAAG0.  Looking at the beginning of flash, I see the magic nuimber, followed by the command to configure the pll1.  All seems well and good.  I next see the command to configure the EMIFA, which seems to be working.  Next I see the command to configure the ddr2.  This is where things seem to stop working.  The ini file that I am using agrees with the values I am seeing in flash (again, I am referencing SRPAAG0 for what the code does).  But when I break into my simple case bootloader, the values for sdbcr, sdtimr, & sdtimr2 registers are all incorrect.  It now would seem that the only reason that this simplified blinky project works is because all memory sections are allocated to IRAM, whereas the project that I thought was failing has most sections allocated in ddr2 which seems to not be configured correctly by the bootloader ROM.

As a side note, the value shown for the pll2 multiplier register when using View->register->pll2 is incorrect.  When I look up the actual location in memory, I see the expected value that I programmed into it.

So I guess the issue I am down to is that the bootloader is not performing ddr2 configuration as I expected.  I have to conclude that I am either basing my work off of incorrect documentation or that there is some problem with the bootloader, because based on SPRAAG0 I expected different results.  BOOTCFG register shows 0x00184104, which is what I expected.

Register          Expected value          Read value

SDBCR           0x01170832               0x01170a32

SDTIMR          0x3a4a2a09               0x356b4b9b

SDTIMR2        0x001fc7e2                0x001df145

Downloaded data from flash, offset is from 0x42000000:

00000000: 00000000 54495041 0D595358 00000300

00000010: 1B000000 00000000 00000000 0D595358

00000020: 01000500 FCFFFF3F FCFFFF3F FCFFFF3F

00000030: FCFFFF3F 00000000 0D595358 02000900

00000040: 17000000 01000000 0B000000 00000000

00000050: 04640050 32081300 092A4A3A E2C71F00

00000060: 92040000 0D595358 03000200 01005400

00000070: 40454000 03595358 01595358 A061F110

00000080: 60000000 13012319 A60CF61A B201A704

00000090: 492DABA2 CA822724 81481292 68E10002

000000A0: 1E80E0E7 0C009124 6E4C0864 EAA101EC

000000B0: EBBE6925 20A11A20 28003103 E9780803

000000C0: 0080E0E1 90EC8CC6 2041E68F 2A0A0002

000000D0: FA921002 0500D026 62A38C00 00000000

000000E0: 020120E2 07595358 03000000 08018201

000000F0: A061F110 00000000 07595358 03000000

Well, I believe that I have solved the issue.  In the value for SDBCR, it seems that it is necessary to set the unlock bit in the AIS .ini file.  If I do that, the other ddr2 registers work fine, and it doesn't matter that I allocate sections to L1D.  The unlock bit is still set after boot completes, is this anything to be concerned about?

I like your vigor in posting your issues and progress on the forum, and I am glad to hear that it sounds like you have fixed it so I can take my time in catching up  :).

MattLipsey said:

Well, I believe that I have solved the issue.  In the value for SDBCR, it seems that it is necessary to set the unlock bit in the AIS .ini file.  If I do that, the other ddr2 registers work fine, and it doesn't matter that I allocate sections to L1D.  The unlock bit is still set after boot completes, is this anything to be concerned about?

I don't see anything wrong with the DDR timing registers still being unlocked after the boot completes as long as you don't have any code that could be inadvertently writing to those registers and changing the timing while the system is up and running. It may be a good idea to lock them again after the timing configuration has completed to ensure they are not erroneously changed, as is suggested by the DDR manual.