Migrating from CCSv3.3 to CCSv4.x using OMAP2430 Configuration

Casey,

Casey Holland said:

1)  In my configuration, I have the connection, a router n(IcePick_B_0), and  3 subpaths under that labeled:  arm w/ARM11 processor, etb w/BYPASSP_ETB processor, and dsp w/C64xx_0 processor.  When I launch the configuration I right-click on the ARM11_0 subpath I created to connect to my target, OMAP2430 processor.  Do I need the other two? 

If you don't need to debug code on the DSP or use the Trace, then you don't need them. In any case, I created a target configuration file based on the page below that contains all the cores and port configurations for an OMAP2430, although CCSv4 is not officially tested on this device. Unfortunately I don't have such board to test this configuration. 

http://processors.wiki.ti.com/index.php/Target_Configuration_-_Custom_Configurations

Casey Holland said:

2)  In my v3.3 configuration, a C6400Plus CPU is setup under the dsp subpath and points to the C6400plus driver.  In v4.x, I don't know how to get the C6400Plus CPU or how to "link" to the C6400plus driver, which is why I chose C64xx_0.  If it is not need from question 1 above, then I have no concern.

Check above. The core is named C64XP.

Casey Holland said:

3)  Before loading memory, I use two files using the "Load Program" option:  x-loader.out and u-boot.out.  Using a u-boot.out file, in v3.3 everything seems to behave normally when I "Load Program".  However, in v4.x, I see a bunch of nand bad block errors and I also see a line in the terminal window after the programming of u-boot that says something like, "bug found in u-boot on line c.248".  I can still complete the process of loading FW through the "Load Memory" option after this step, but I don't see this sort of behavior with v3.3 and didn't know if I had corrupted u-boot files or needed new ones or what.

I am not sure what is happening here, as the CCSv4 loader can't load anything to NAND flash memory for this device. I would inspect the error messages' addresses and verify if they are writable using the memory view. Another thing I would try is to reduce the JTAG CLK frequency of the emulator and see if you can get a more reliable connection. Maybe something is not quite right on the communications channel.

Again, CCSv4 is not tested in OMAP2 devices, therefore I hope this is not the root cause for these access errors.  

Hope this helps,

Rafael